On Sun, May 16, 2010 at 2:34 AM, Tom Hawkins wrote:

...

I got the GADT

data DataBox where   DataBox :: (Show d, Eq d, Data d) => d -> DataBox

[snip]

...

but I can't figure out how to implement gunfold for DataBox.

The error message is

Text/XML/Generic.hs:274:23:     Ambiguous type variable `b' in the constraints:

I had a similar difficultly in Atom making a GADT a member of Eq.  At one point I had my head wrapped around the reason for the problem, but now it escapes me.  However, I remember the solution: I created a function to convert the GADT into another, unGADT type, which was then used to compute (==). _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Have you tried using StandaloneDeriving (and DeriveDataTypeable)? According to http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/deriving.html#stand-... you can't derive instances for GADTs normally but a standalone derivation will at least attempt to make an instance as if it was an ordinary data type.

Hi, thanks for all the great feedback.

Your GADT encodes an existential datatype. The closest attempt to encode existential types in (something like) SYB that I know of is in Section 5.3 of Alexey's PhD thesis [1]. Having said that, he uses the spine view, which makes the generic view in SYB explicit, but this has never been packaged as a library. So I'm afraid the answer is "no". The link above might still be useful for your understanding of why this is a complex problem, though.

Interesting paper by Alexey. Especially p. 106.

Have you tried using StandaloneDeriving (and DeriveDataTypeable)?

Thanks for the tip. Didn't know about this feature before but unfortunately it didn't help me. Standalone deriving gave the same error message so I guess it generates similar code to what I wrote.

forall d. gunfold k z c = k (z (DataBox::d->DataBox d))

Didn't work either. :(

Also why isn't the paramater c used?

I guess c says which constructor is used, but since I know which constructor is used (since DataBox only got one) the variable is discarded.

However, I remember the solution: I created a function to convert the GADT into another, unGADT type,

Is this possible for existential data types too? I tried to convert DataBox to a data type "DataBox' a" but I couldn't get it to compile. Are there any libraries for generics/reflection that can handle existential data types? EMGM/multirec/? Until I manage to figure this out I'll go with the technique described in http://okmij.org/ftp/Computation/Existentials.html where instead of exposing a function

decodeUnknownXML :: String -> Maybe DataBox

the package expose a function

decodeUnknownXML :: Data a => String -> (a -> b) -> Maybe b

-- Oscar 2010/5/16 José Pedro Magalhães

Hi Oscar,

On Sat, May 15, 2010 at 22:19, Oscar Finnsson wrote:

...

(...)

I guess my questions are:

1. Is it possible to combine GADTs with Scrap your Boilerplate?

Your GADT encodes an existential datatype. The closest attempt to encode existential types in (something like) SYB that I know of is in Section 5.3 of Alexey's PhD thesis [1]. Having said that, he uses the spine view, which makes the generic view in SYB explicit, but this has never been packaged as a library. So I'm afraid the answer is "no". The link above might still be useful for your understanding of why this is a complex problem, though.

Cheers, Pedro

[1] http://igitur-archive.library.uu.nl/dissertations/2009-0518-200422/UUindex.h...

On May 18, 2010, at 3:27 PM, John Creighton wrote:

I looked again at the paper (page 27): Haskell's Overlooked object system. http://homepages.cwi.nl/~ralf/OOHaskell/paper.pdf

Is there any particular reason why you like that paper so much? Object orientation is nice, when you're dealing with "object-like" normal forms (that's actually quite rare, for most models of OO. The actor model is the only one I can think of off-hand with a "natural" interpretation). Otherwise, it's just an extra, unnecessary layer of abstraction.