We need to add role annotations for 7.8

Mark Lentczner mark.lentczner at gmail.com
Mon Mar 24 14:44:07 UTC 2014

On Mon, Mar 24, 2014 at 7:28 AM, Brandon Allbery <allbery.b at gmail.com>wrote:

> No; if the default is representational, everything works as it did in
> earlier versions, potential bugs/unsafety and all. If the default is
> immediately switched to nominal, *then* every affected type must be
> reviewed immediately.

Now I'm confused about the current state of the default....

But it doesn't matter either way: The Platform is expected to work
cohesively with the GHC release, and either of these defaults spells a huge
amount of work for the Platform.

> My counter-proposal was to have 7.8 default to representational to give
> library maintainers a release cycle to add the necessary annotations, then
> switch the default to nominal in 7.10 to get the additional safety.

This is unworkable. How much conditional code do you want library writers
to have to have? Library writers strive to have code which works with n
prior releases where n is commonly 3. Having code that works with 7.6, 7.8,
and 7.10 would be a nighmare!

On Mon, Mar 24, 2014 at 7:32 AM, Brandon Allbery <allbery.b at gmail.com>

> perhaps there should be some mechanism to specify to ghc 7.8 whether a
> compile should default to representational or nominal so that authors have
> a way to test their code / look for problems.

Also unworkable... now we need a conditional flag for the state of the
default so the code can be written to work with either based on a GHC flag?
And how is that supposed to work with already compiled dependencies
(sandboxed or not)? Is cabal now to take this flag into account? the
Package manager signatures too?

The major problem with this feature is that it is massively global in
scope. This is extremely rare for GHC extensions (Safe comes to mind)...
and with good reason: It is very very expensive. The motivating case here,
a compiler checked safe zero-cost coerce, seems way out of proportion to
the cost: Careful review of every library abstract type, and addition of
*three+* lines of source (remember, this must be CPP guarded, so you have
to add CPP extension on to every file, too).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20140324/44806c2a/attachment.html>

More information about the Libraries mailing list