Re: Propsal: NoDatatypeContexts
+1 On Sunday, July 18, 2010, Ian Lynagh wrote: > > Hi all, > > H98 and H2010 allow a context to be given for datatypes, e.g. the > "Eq a" in > > data Eq a => Foo a = Constr a > > I have made a proposal to remove support for that context (ticket #139). > More details are on the proposal wiki page: > > http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts > > > Thanks > Ian > > ___ > Haskell-prime mailing list > Haskell-prime@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-prime > ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Propsal: NoDatatypeContexts
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/ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Propsal: NoDatatypeContexts
H98 and H2010 allow a context to be given for datatypes, e.g. the "Eq a" in data Eq a => Foo a = Constr a I have made a proposal to remove support for that context (ticket #139). Although I would prefer that contexts of datatypes did the right and useful thing, in the absence of a proposal of that nature, I am quite happy to add my +1 to their removal instead. 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 Regards, Malcolm ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Propsal: NoDatatypeContexts
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.mae...@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
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Propsal: NoDatatypeContexts
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.
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 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
> http://www.haskell.org/mailman/listinfo/haskell-prime
>
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Propsal: NoDatatypeContexts
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
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Propsal: NoDatatypeContexts
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 ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
RE: Propsal: NoDatatypeContexts
I believe there is no such case. Data type contexts are a mis-feature and should never have been in Haskell. Simon | -Original Message- | From: haskell-prime-boun...@haskell.org [mailto:haskell-prime- | boun...@haskell.org] On Behalf Of Thomas Schilling | Sent: 19 July 2010 23:14 | To: haskell-prime@haskell.org | Subject: Re: Propsal: NoDatatypeContexts | | On 18 July 2010 22:59, Ian Lynagh wrote: | > I have made a proposal to remove support for that context (ticket #139). | > More details are on the proposal wiki page: | > | > http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts | | +1 | | I would be interested in a case where it actually *is* a good idea to | use such contexts. From my understanding, if you want to enforce the | constraints on users of your library you can still export it as an | abstract data type and put the constraints on the functions that use | it. | ___ | Haskell-prime mailing list | Haskell-prime@haskell.org | http://www.haskell.org/mailman/listinfo/haskell-prime ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Propsal: NoDatatypeContexts
On 18 July 2010 22:59, Ian Lynagh wrote: > I have made a proposal to remove support for that context (ticket #139). > More details are on the proposal wiki page: > > http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts +1 I would be interested in a case where it actually *is* a good idea to use such contexts. From my understanding, if you want to enforce the constraints on users of your library you can still export it as an abstract data type and put the constraints on the functions that use it. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Propsal: NoDatatypeContexts
On Mon, Jul 19, 2010 at 11:29:37AM +0200, Christian Maeder wrote:
> 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.
>
> However, ghc is able by "deriving (Show, Read)" to see
>
> instance (Ord symbol, Read sign, Read symbol) =>
> Read (ExtSign sign symbol)
>
> without the context.
Hmm... if you can provide a fix for this I'll integrate it, perhaps a
manual annotation will be the only way, I don't think there is any easy
way for DrIFT to derive that information otherwise.
John
--
John Meacham - ⑆repetae.net⑆john⑈ - http://notanumber.net/
___
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Propsal: NoDatatypeContexts
http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts +1 -- Underestimating the novelty of the future is a time-honored tradition. (D.G.) ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Propsal: NoDatatypeContexts
Ian Lynagh schrieb:
> Hi all,
>
> H98 and H2010 allow a context to be given for datatypes, e.g. the
> "Eq a" in
>
> data Eq a => Foo a = Constr a
>
> I have made a proposal to remove support for that context (ticket #139).
> More details are on the proposal wiki page:
>
> 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.
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
http://www.haskell.org/mailman/listinfo/haskell-prime
Re: Propsal: NoDatatypeContexts
On 18/07/10 22:59, Ian Lynagh wrote: Hi all, H98 and H2010 allow a context to be given for datatypes, e.g. the "Eq a" in data Eq a => Foo a = Constr a I have made a proposal to remove support for that context (ticket #139). More details are on the proposal wiki page: http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts To provide a data point: I was surprised to see CHP on the list of packages that didn't compile without data-type contexts, as I didn't realise I was using them. I found one in a source file I haven't touched for a while, and removing it made no difference -- the library compiled fine. I'm all for the proposal -- it stops people (like me!) inadvisedly using datatype contexts despite them not actually doing anything. Thanks, Neil. ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
Propsal: NoDatatypeContexts
Hi all, H98 and H2010 allow a context to be given for datatypes, e.g. the "Eq a" in data Eq a => Foo a = Constr a I have made a proposal to remove support for that context (ticket #139). More details are on the proposal wiki page: http://hackage.haskell.org/trac/haskell-prime/wiki/NoDatatypeContexts Thanks Ian ___ Haskell-prime mailing list Haskell-prime@haskell.org http://www.haskell.org/mailman/listinfo/haskell-prime
