limitations of newtype-derivings (fixed)

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