Re: We need to add role annotations for 7.8
Gershom Bazerman <[email protected]> Mon, 24 Mar 2014 10:57:27 -0400
| Newsgroups | gmane.comp.lang.haskell.libraries,gmane.comp.lang.haskell.cvs.ghc |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format.
--===============1377527248009082114==
Content-Type: multipart/alternative;
boundary="------------090409040005080107050903"
This is a multi-part message in MIME format.
--------------090409040005080107050903
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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).
>
--------------090409040005080107050903
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Apols if I'm overstating the case, but
let me try to clear things up.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
-g<br>
<br>
On 3/24/14, 10:44 AM, Mark Lentczner wrote:<br>
</div>
<blockquote
cite="mid:CAAOoiFbjjEMRtOgXPV=P6nKNhEzRy2hhH94qWdaHO=NwLZufWw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><br>
<div>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 <b>three+</b> lines of
source (remember, this must be CPP guarded, so you have to
add CPP extension on to every file, too). <br>
</div>
</div>
</div>
</div>
<br>
</blockquote>
<br>
</body>
</html>
--------------090409040005080107050903--
--===============1377527248009082114==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
Libraries mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/libraries
--===============1377527248009082114==--