Re: We need to add role annotations for 7.8
On Mon, Mar 24, 2014 at 7:28 AM, Brandon Allbery
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
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).
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).
participants (2)
-
Gershom Bazerman -
Mark Lentczner