Exposing newtype coercions to Haskell

[Joachim Breitner]

Hi,

Am Montag, den 15.07.2013, 21:57 +0000 schrieb Simon Peyton-Jones:
> ·       note that the “seq” nonsense is because we allow user-defined
> NT-values

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

> ·       also note that to determine which NT values we can derive from
> in-scope NT values, we have to do something very similar to type-class
> solving.  Eg. need NT [T] [S], have available ntList :: forall ab. NT
> a b -> NT [a] [b], so use ntList to simplify NT [T] [S] to NT T S.

Yes, as discussed.

> Hence the following suggestion: revert from NT as a data value to NT
> as a class.  Thus
> 
>           class NT a b where
>             castNT :: a -> b
>             uncastNT :: b -> a

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.

I assume that the “real” NT class will be abstract and castNT/uncastNT
exposed as normal functions, not class methods, so that the user does
not create custom instances, right?


> You might worry that instances are not scopeable.  Quite right.  If
> you make an NT instance, *everyone* can see it. So don’t make a type
> an instance of NT unless that’s want.  This is not terrible; it just
> means that you can’t make *local* NT instances, just as you can’t make
> local Eq instances.

The thing is that I don’t need local Eq instances; I can just call my
local private myCustomEq. But I cannot create a local private coercion. 

I guess one can argue that if someone has such special needs, he will be
able to figure out when to use unsafeCoerce, and just let them play in
the rough outsides. So the missing feature can at least functionally
approximated (just as it can be now).

> Does that make sense?

Nothing new here besides the point that the feature „private, unexposed
NT coercions“ do not warrant the extra overhead of introducing new
syntax and replicating the deriving feature on the function level, and
I’ll take that point.

I guess it doesn’t change the implementation a lot, although I probably
can’t implement that in a plugin any more. Although it would actually be
a useful thing if code for deriving new type classes can be added in a
plugin :-)

So I’ll soon start implementing that.

Greetings,
Joachim


-- 
Joachim “nomeata” Breitner
  mail at joachim-breitner.de • http://www.joachim-breitner.de/
  Jabber: nomeata at joachim-breitner.de  • GPG-Key: 0x4743206C
  Debian Developer: nomeata at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130716/ea03f732/attachment.pgp>