Re: limitations of newtype-derivings (fixed)
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 deriving, like this: deriving instance Show Foo -- Cheers, Dinko ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
RE: limitations of newtype-derivings (fixed)
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 to be separate from data | definitions. | | basically, we would allow deriving anywhere. | | 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. | 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 newtype deriving, we can do: | | deriving(MapLike Id Term Subst) Now things aren't so clear. You are assuming that we have an instance instance MapLike Int a (IntMap a) But suppose we also had an explicit instance decl for instance MapLike Int Term Subst which we might. Which would the 'deriving' base its instance on? We might also have an explicit instance instance MapLike Id a (IntMap a) Now it's even less obvious which to use. What if the newtype was buried more deeply. Can we say deriving( C (Foo Id) ) if we happen to have an instance for C (Foo Int) around already? Here the newtype isn't at the top level of the class argument. GHC's newtype-deriving mechanism is very precise: it unwraps exactly one layer of exactly one newtype. It's attractive to go further, as you describe, but it'd need to be tightly specified. (And of course, that increases the complexity of the overall language.) Simon ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: limitations of newtype-derivings (fixed)
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 newtype deriving, we can do: | | deriving(MapLike Id Term Subst) Now things aren't so clear. You are assuming that we have an instance instance MapLike Int a (IntMap a) But suppose we also had an explicit instance decl for instance MapLike Int Term Subst which we might. Which would the 'deriving' base its instance on? We might also have an explicit instance instance MapLike Id a (IntMap a) Now it's even less obvious which to use. good point. We would probably want to specify which instance we are deriving it from with something like deriving (MapLike Int a (IntMap a) = MapLike Id Term Subst) being explicit seems better than making up some resolution rules. What if the newtype was buried more deeply. Can we say deriving( C (Foo Id) ) if we happen to have an instance for C (Foo Int) around already? Here the newtype isn't at the top level of the class argument. I had not thought about that. A use doesn't occur to me off the top of my head, but that is probably just because it hasn't been available so I have not considered uses of it. I see no particular problem assuming all the constructors of Foo and Id and the methods of C are in scope. GHC's newtype-deriving mechanism is very precise: it unwraps exactly one layer of exactly one newtype. It's attractive to go further, as you describe, but it'd need to be tightly specified. (And of course, that increases the complexity of the overall language.) yeah, the restriction that you can only newtype derive the last argument has always bothered me with its arbitraryness based solely on syntax. so getting rid of that restriction would simplify the language. coderiving (is there a better term?) instances based on multiple newtypes is a true new feature, but I don't see any issues from an implementation standpoint, just the same problem of defining it without saying the same method We also have a few derivings which are special, 'Show,Read,Typeable,Data' that don't follow the newtype deriving rule, but I am not proposing we change them. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
Re: limitations of newtype-derivings (fixed)
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 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 to be separate from data definitions. basically, we would allow deriving anywhere. deriving (Show Foo) means the same thing as data Foo = ... deriving (Show) will derive an instance of Show for Foo. now we are no longer bound by either of the above constraints.. imagine we have a class class MapLike k v m | m - k v where insert :: .. delete :: ... ... instance MapLike Int a (IM.IntMap a) where insert = IM.insert now, we want a newtype that describes Id's. newtype Id = Id Int deriving(Eq,Ord) now, we want to create a type of substitutions from Ids - Terms 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 newtype deriving, we can do: deriving(MapLike Id Term Subst) and be done with it. this would be worlds of useful. John -- John Meacham - ⑆repetae.net⑆john⑈ ___ Haskell-prime mailing list Haskell-prime@haskell.org http://haskell.org/mailman/listinfo/haskell-prime
