We need to add role annotations for 7.8

[Gershom Bazerman]

Apols if I'm overstating the case, but let me try to clear things up.

Roles are not in place to provide a "safe" cheap coerce. Roles are in 
place to _prevent_ an unsoundness with newtype deriving in the presence 
of type families. They also happen to _allow_ a cheaper coerce. The 
unsoundness is fixed by roles, with or without specific role 
annotations, because the necessary roles for type-safety (preventing 
segfault) are inferred/enforced regardless.

With or without roles, in the past, it has been possible to circumvent 
certain mechanisms of abstraction by using newtype deriving. Explicit 
roles now _allow_ library writers to, for the first time, to enforce 
these abstraction mechanisms more strongly than in the past. We also 
happen to have a new "coerce" that will not segfault, and _if_ role 
annotations are correct, will respect representation-hiding. If 
libraries do _not_ get updated with roles, the "worst" that can happen 
is that their abstractions are precisely as deliberately circumventable 
as in the past, although there is now an "easy" function provided that 
makes this circumvention more straightforward.

So I feel it is "better" to enforce representation-hiding through proper 
usage of roles. However, it is also no great sin to _not_ enforce it for 
some span of time, since all that doing so prevents is a rather (at the 
moment) esoteric mechanism for developers to shoot themselves in the 
foot -- a mechanism that in a slightly different form has existed all along.

-g

On 3/24/14, 10:44 AM, Mark Lentczner wrote:
>
> 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/a4d64371/attachment.html>