limitations of newtype-derivings (fixed)

[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 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