| Many of you have run across the problem with
| newtypes that, although it is very cheap to
| coerce between the newtype and the base type, it
| can be very expensive to coerce between, say,
| a list of the newtype and a list of the base type.
| Stephanie Weirich and I are working on a proposal
| for the Haskell Workshop addressing this problem,
| and we would welcome any feedback from the community.
Thanks for the draft, which I read last night. Interesting.
I have two main comments.
1. Personally, I've never actually been bitten by this problem.
Have you? In other words, how practically important is it?
(Regardless, it's a wart, I must agree.)
2. More substantially, you describe your solution as lightweight,
but it involves quite a bit: multi-param type classes, automatic
derivings.. And STILL the programmer has to fiddle about with
frankly non-obvious constructions (Section 4). So I have an
alternative suggestion: provide 'cast' in the language.
That is, if e :: t
then (cast e) :: s
for any type s that has the same representation as t.
So I need to add some rules saying what it means to 'have the
same representation' but that's pretty easy. And there's no problem
with nested types.
What made me think about this is that GHC internally has exactly such
a thing (it's called 'coerce' rather than 'cast'). Newtype constructors
are compiled into applications of 'coerce', and similarly pattern matching.
It seems bizarre to require the *programmer* to write complicated code
(like (Apl . f . unApl)) in order to get the *compiler* to produce the very
simple code (cast t). That's back to front!
One could also deal with the abstraction issue: you can say
that two types have the same representation iff you could convert
a value of one type into a value of the other, *using the constructors
currently in scope*. So if the ADT doesn't expose the constructors
you can't cast.
There is also the question of whether newtype is a good thing at all.
Maybe we'd be better off with Gofer's restricted type synonyms.
Simon
