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
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⑈
On 4/11/06, Simon Peyton-Jones
| > 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
participants (3)
-
Dinko Tenev -
John Meacham -
Simon Peyton-Jones