limitations of newtype-derivings (fixed)

[John Meacham]

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⑈