Christian Maeder schrieb:

Ian Lynagh schrieb: [...]

...

http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts

I'm for this proposal, although I've got an example where I need this context, namely for DrIFT to derive a proper context for instances.

DrIFT doesn't know that the Read instance for Data.Set.Set relies on Ord of the elements. For

data Ord symbol => ExtSign sign symbol = ExtSign { plainSign :: sign , nonImportedSymbols :: Set.Set symbol } deriving Show

DrIFT cannot derive the Read (or our deserialization) instance without the "Ord symbol =>" context.

It would be interesting to know (or if at all) i.e. uniplate (proposed for the haskell platform) or other generic stuff can handle this case (as alternative to DrIFT). A short look at http://www.haskell.org/haskellwiki/Uniplate did not immediate help on this matter. Template Haskell may be possible, too. Can some expert for generic programming elaborate on this? (I once had a good paper comparing the various approaches, but I can no longer find it.) Pointers are welcome. Cheers Christian

However, ghc is able by "deriving (Show, Read)" to see

instance (Ord symbol, Read sign, Read symbol) => Read (ExtSign sign symbol)

without the context.

Cheers Christian

José Pedro Magalhães schrieb:

Hello all,

...

DrIFT cannot derive the Read (or our deserialization) instance without the "Ord symbol =>" context.

That's because DrIFT is simply copying this context to the Read instance, right? Perhaps the best way to do it would be to copy the context of the Read instance for Set and use that instead (though I know that DrIFT does not have access to that).

...

It would be interesting to know (or if at all) i.e. uniplate (proposed for the haskell platform) or other generic stuff can handle this case (as alternative to DrIFT).

From what I know, most generic programming approaches simply ignore constrained datatypes. I thought about them in the design of a generic programming library for replacing the Haskell deriving mechanism [1]. I think it's easy to support them, but actually we don't support them, since we also think they are not used very often and should disappear.

I agree, that the context on datatypes should be ignored and disappear. But I still want to derive a deserialization instance (like for "Read") with the proper context (i.e. without manual interaction) from the component types (like ghc can somehow by "deriving Read" if Data.Set.Set is a type component). Thanks Christian

Cheers, Pedro

[1] José Pedro Magalhães, Atze Dijkstra, Johan Jeuring, and Andres Löh. A generic deriving mechanism for Haskell. http://dreixel.net/research/pdf/gdmh_draft.pdf (see Section 7.1 for the discussion on constrained datatypes)

On Tue, Jul 20, 2010 at 10:46, Christian Maeder mailto:Christian.Maeder@dfki.de> wrote:

Christian Maeder schrieb: > Ian Lynagh schrieb: [...] >> http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts > > I'm for this proposal, although I've got an example where I need this > context, namely for DrIFT to derive a proper context for instances. > > DrIFT doesn't know that the Read instance for Data.Set.Set relies on Ord > of the elements. For > > data Ord symbol => ExtSign sign symbol = ExtSign > { plainSign :: sign > , nonImportedSymbols :: Set.Set symbol > } deriving Show > > DrIFT cannot derive the Read (or our deserialization) instance without > the "Ord symbol =>" context.

It would be interesting to know (or if at all) i.e. uniplate (proposed for the haskell platform) or other generic stuff can handle this case (as alternative to DrIFT).

A short look at http://www.haskell.org/haskellwiki/Uniplate did not immediate help on this matter.

Template Haskell may be possible, too.

Can some expert for generic programming elaborate on this? (I once had a good paper comparing the various approaches, but I can no longer find it.)

Pointers are welcome.

Cheers Christian

> > However, ghc is able by "deriving (Show, Read)" to see > > instance (Ord symbol, Read sign, Read symbol) => > Read (ExtSign sign symbol) > > without the context. > > Cheers Christian _______________________________________________ Haskell-prime mailing list Haskell-prime@haskell.org mailto:Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime

On 19 July 2010 23:14, Thomas Schilling wrote:

I would be interested in a case where it actually *is* a good idea to use such contexts.

If you don't have kind signatures, you can use them as a hack to change the inferred kind for an EmptyDataDecl """ -- a has kind * data Foo a """ """ class Stupid a where unused :: a () -- a has kind (* -> *) data Stupid a => Foo a """ I think HList was using this kind of hack until recently. Cheers, Max

On Tue, Jul 20, 2010 at 07:47:34PM +0100, Malcolm Wallace wrote:

As Igloo notes, GADTs are a more viable way to achieve the storing of the dictionary within the constructor, e.g.

data OrdTree a where Leaf :: a -> OrdTree a Branch :: Ord a => OrdTree a -> OrdTree a -> OrdTree a

I was thinking about this case the other day from an implementation point of view, wouldn't it annotate every subnode of a tree with an extra ord instance, which are guarenteed to be the same anyway? Something like import Data.Set data OrdSet a where OrdSet :: Ord a => Set a -> OrdSet a then using the normal set operations seems like it would be more efficient. It seems like it would be easy to accidentally end up with extra instances being passed around with the current GADT system. Another alternate proposal for what we might do with data contexts that was floating around was to have them allow smaller type signatures. data Ord a => Set a = .. would mean that whenever you see a 'Set a' the 'Ord a' is implied and need not be explicitly stated. so insert :: a -> Set a -> Set a is shorthand for insert :: Ord a => a -> Set a -> Set a John -- John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/