limitations of newtypederivings (fixed)
Simon PeytonJones
simonpj at microsoft.com
Tue Apr 11 09:19:22 EDT 2006
I like this idea. Needs fleshing out though.
 * you can only newtype derive the last argument to a MPTC.
 * you cannot coderive 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 newtypederiving 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
More information about the Haskellprime
mailing list