Exposing newtype coercions to Haskell

[Simon Peyton-Jones]

| Are you saying that seq is nonsense? Or that are you just telling me why
| we need seq?

No, no, just that all those seqs are big nuisance -- and one caused solely by the fact that users could (in effect) write bogus instances. If they can't, the issue doesn't arise.

| We’ve discussed this proposal before. The only problem with it is that
| it will not allow the author of a type container which should be
| abstract to cast it in internal code; if that is ok then type classes
| are definitely the nicer way.

OK. 

The whole story is *so* much simpler if we piggy back on type classes that I think that's a much better way to go.  OK, so you can't do "deep casting" of internal data types without exposing the ability to "deep cast" to clients.  But we have no convincing examples of such a need.

Let's do the simple thing.

| I guess it doesn’t change the implementation a lot

Oh I think it does change it a LOT.  No more hunting through all the in-scope identifier for ones whose type finish with ".... -> NT t1 t2".  No new syntax. No new type-class-like deduction algorithm.  It all just plays out through the existing type class machinery.

| Although it would actually be
| a useful thing if code for deriving new type classes can be added in a
| plugin :-)

Indeed. One answer is "generics".  Another is to have a mechanism for a front-end plugin.  But let's not bend this feature out of shape to serve that goal. Better to design a better plugin mechanism.

Simon