[Hs-Generics] EMGM: deriving instances

[Sean Leather]

Hi Antoine,

This is listed as the mailing list for EMGM on its website:
> http://www.cs.uu.nl/wiki/GenericProgramming/EMGM
>

You came to the right place. Thanks for trying out EMGM!

I'm not sure if I'm using the template Haskell deriving properly for
> EMGM instances - I doesn't work for me for:
>
>  + Data declarations which contain type synonyms
>  + Data declarations which contain a Bool
>

You are using it correctly, but there are some limitations in the current
implementation.

I get errors like:
>
> >>>>>
>    Exception when trying to run compile-time code:
>      Error! Unsupported constant type: Bool
>      Code: EMGM.derive 'A
> <<<<<
>

This error comes from these lines in Generics.EMGM.Common.Derive.Instance:

104> -- Given a name for a constant type and the rep option, get an
appropriate
105> -- expression name.
106> conTypeExpName :: Name -> RepOpt -> Name
107> conTypeExpName typeName =
108>   case nameBase typeName of
109>     "Int"     -> rintN
110>     "Integer" -> rintegerN
111>     "Float"   -> rfloatN
112>     "Double"  -> rdoubleN
113>     "Char"    -> rcharN
114>     n         -> error $ "Error! Unsupported constant type: " ++ n

EMGM's Template Haskell deriving doesn't currently handle a non-"primitive"
type contained in functor types such as all of your types. Right now, types
such as your A can only contain the above-listed primitives or other functor
types (e.g. B, Maybe, or []).

I get a similar error if my data type uses a 'String' instead of a
> Bool, but the error for the String goes away if I use [Char] instead.
>

Yes, it doesn't resolve type synonyms. It works with [Char], because [] is a
functor type (kind * -> *) and Char is a primitive constant type.


> Is this expected behavior?  If I'm just running into the limits of
> what EMGM template-Haskell deriving can do, that's okay.  I just
> didn't see these limitations described anywhere.
>

Unfortunately, it is expected behavior. I was afraid somebody would run into
this; I just didn't know how long it would take. ;)

I'm using GHC 6.10, with emgm-0.2 from hackage.
>
> Here's the sample program I'm working with:
>
> >>>>>
> {-# LANGUAGE TemplateHaskell
>           , MultiParamTypeClasses
>           , FlexibleContexts
>           , FlexibleInstances
>           , OverlappingInstances
>           , UndecidableInstances
>  #-}
>
> import qualified Generics.EMGM as EMGM
>
>
> data MyData a = MkMyData
>    { name :: [Char]
>    -- , flag :: Bool
>    -- , otherName :: String
>    , fa :: A a
>    , fb :: B a
>    }
>
> data A a = MkA Int Bool a
>
> data B a =  MkB Char a
>
> $(EMGM.derive ''MyData)
> $(EMGM.derive ''A)
> $(EMGM.derive ''B)
> <<<<<
>

So, from what you say, your problem is with String and Bool?

If you want immediate satisfaction and you're only using functions based on
Rep (i.e. not FRep, FRep2, etc.), then you can change your deriving code to
this:

> import Generics.EMGM.Common.Derive

> $(declareConDescrs ''A)
> $(declareEP ''A)
> $(deriveRep ''A)

> $(declareConDescrs ''B)
> $(declareEP ''B)
> $(deriveRep ''B)

> $(declareConDescrs ''MyData)
> $(declareEP ''MyData)
> $(deriveRep ''MyData)

"deriveRep" doesn't care whether a type is primitive or not. It does the
same thing for every type, notably use the "rep" method as type
representation.

Otherwise, you'll have to wait on a fix. ;)

The problem with functor/bifunctor type representation is not just with the
deriving part. It deals with the more fundamental problem of, for example,
representing a functor type using the "Generic2" class that contains
non-functor types normally be represented using the "Generic" class.

I think I can fix EMGM to handle this and other cases where you're using
either type synonyms or representations from the EMGM library.

Let me see what I can do today or tomorrow, and I'll push out an update.

Thanks for letting us know that you encountered this problem. It motivates
me to improve things. ;)

Regards,
Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/generics/attachments/20090219/cc945d72/attachment.htm