Propsal: NoDatatypeContexts

[Christian Maeder]

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
> <Christian.Maeder at dfki.de <mailto:Christian.Maeder at 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 at haskell.org <mailto:Haskell-prime at haskell.org>
>     http://www.haskell.org/mailman/listinfo/haskell-prime
> 
>