> However, if the transforming program took into account the information in the
> type signature (for unionMany, it would notice that the user used the type
> synonym for the inner list only), it could make pretty good guesses about which
> arguments and results to unpack or pack.
> Since the additional constructor applications and pattern matches in "newtype"
> ADTs makes them harder to read and write, I think it is useful to be able to
> generate them automatically from simpler, "type" ADTs. Assuming that there
> are no other problems, maybe one could define some sort of derivation
> mechanism for such ADTs so that they would be imported abstractly:
>
> import Set'(newtype Set', union', unionMany')
> = abstract Set(type Set, union, unionMany)
There's some disucussion about the shortcomings of newtype on the
Standard Haskell web page. The difficulty with the proposal you make
is that I no of no precise definition for "some sort of derivation
mechanism". A language definition can't "make pretty good guesses".
It has to precisely specify the meaning of every program.
The dilemma here is that we know that newtype has deficiencies for defining
ADTs, but we don't know a well defined and clearly superior alternative. The
one that comes closest is Gofer's restricted type synonyms. Newtype has the
important advantage that it's quite clear what a program means, and what
its type is.
Simon
