We need to add role annotations for 7.8

[Edward Kmett]

Mark,

We're currently planning to retain the existing behavior of
GeneralizedNewtypeDeriving with regards to Safe Haskell. That is, Safe
Haskell and GND still won't mix in 7.8 due to these same security concerns.

I think a key observation with regards to GeneralizedNewtypeDeriving is
with representational roles as default the new roles machinery with the
representational default lets you write nothing you couldn't write before.
No new security vulnerabilities are introduced. They were there all along!

We're also disabling the Safe flag on Data.Coerce. In that light, `coerce`
then can be viewed as a more friendly but still evil version of
unsafeCoerce. It lets you write nothing you couldn't write before with
`unsafeCoerce`. I view it as merely an occasional situational improvement
over the existing unsafeCoerce in that it at least enforces
representational equality.

Making the default role annotation nominal comes at a very very real cost.
Namely, *all* of generalized newtype deriving anywhere breaks, and everyone
forever will have to put annotations in to fix it.

The 'backwards' representational default puts the burden on a small
minority of library authors.

I'm not a huge fan of the representational machinery, in that it hoists us
upon this dilemma, but given the choice between everyone paying in
perpetuity and a small minority of skilled library authors adding a handful
of annotations that for the most part have already been added, and which
expose them to no more risk than they'd had before if they forget, I'm
definitely in favor of the current solution.

-Edward

On Mon, Mar 24, 2014 at 11:26 AM, Mark Lentczner
<mark.lentczner at gmail.com>wrote:

> Thanks for the pointers, Simon. I appologize for coming to this quite so
> late... I didn't realize the global impact of this feature.
>
> From a "meaning" perspective, I'm agnostic on the default.
> From a "engineering" perspective, I want a default that "does a good
> enough, reasonably safe thing" if programmers ignore the feature.
>
> The later is subtle as there are different vantage points for different
> developers. In the Platform, we have many libraries that we are encouraging
> both end-programmers, and other library authors to make use of and depend
> on extensively. This means those libraries have to work for both
> programmers that are ignoring the feature, and those that use it. In that
> later case, there is the even more subtle distinction of those that use the
> feature for their own code, and those that use it in libraries they make
> available.
>
> The later case is issue: It seems a real mess if a library author who
> wanted to use the new feature, had to circumvent a HP library because it
> didn't annotate. Similar thought experiment: What would be the downside if
> containers didn't annotate? Would that just make the feature unusable
> because everything uses containers?
>
> To put it more directly: with the satus-quo default of representations,
> what is the down side if a library, a widely used library, doesn't bother
> to annotate? What would be the loss if containers didn't annotate? (I know
> it did, this is the thought experiment... because I've got 30+ libraries in
> HP that are in this boat.)
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140324/c4230c12/attachment.html>