Re: limitations of newtype-derivings (fixed)

2006-04-12 Thread Dinko Tenev
On 4/11/06, Simon Peyton-Jones <[EMAIL PROTECTED]> wrote: > | > deriving (Show Foo) > > I'm all for that. A modest but useful gain. All we need is the syntax, > and that is something that Haskell Prime might usefully define. Speaking of which, how about simply qualifying a body-less instance with

Re: limitations of newtype-derivings (fixed)

2006-04-11 Thread John Meacham
On Tue, Apr 11, 2006 at 02:19:22PM +0100, Simon Peyton-Jones wrote: > | > newtype Id = Id Int > | > data Term = ... > | > newtype Subst = Subst (IM.IntMap Term) > | > | ideally, we'd like an MapLike instance, but we'd have to tediously > write > | it ourselves. if we allow the supergeneralized new

RE: limitations of newtype-derivings (fixed)

2006-04-11 Thread Simon Peyton-Jones
I like this idea. Needs fleshing out though. | * you can only newtype derive the last argument to a MPTC. | * you cannot co-derive an instance for multiple newtype renamings. | | it seems that both these can be solved when combined with the other | proposed extension, allowing deriving clauses

Re: limitations of newtype-derivings (fixed)

2006-04-08 Thread John Meacham
ooops. sorry, I started with a 'Set' example and moved to a 'Map' one and didn't fix all the code. here is a fixed version: = The newtype deriving extension is one of the most powerful tools for writing robust, typesafe code. However it suffers from a couple limitations. * you can only newt