limitations of newtype-derivings (fixed)
john at repetae.net
Sun Apr 9 01:08:51 EDT 2006
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
* 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
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
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 Meacham - ⑆repetae.net⑆john⑈
More information about the Haskell-prime