We need to add role annotations for 7.8

[Johan Tibell]

So is the goal that all library authors will add role annotations in the
future? If that doesn't happen, what does that mean for users of coerce?
Will they just have to be careful in what they coerce and make sure that if
their library internally uses coerce that library is only used with types
that have correct role annotations?


On Fri, Mar 14, 2014 at 3:22 PM, Richard Eisenberg <eir at cis.upenn.edu>wrote:

> My expectation matches Brandon's, that making roles default to nominal
> would break lots of code and therefore have a higher cost than defaulting
> to representational (well, phantom actually, but that's a rarer case).
>
> As for issuing a warning, I've thought about this some, but I don't know
> the right place to detect and issue it. Do we want to warn about any
> parameterized datatype definition without a role annotation? (That's a lot
> of them!) Do we want to warn only about abstractly-exported datatypes
> without role annotations? (But, what about types exported concretely from
> an internal, hidden module and then re-exported abstractly?) Do we want to
> warn at use sites? (But then the warning is more about the library than the
> use site.) It's all quite thorny, and several of us have thought about this
> all for a while with no strong conclusion.
>
> So, the best thing we came up with is this: Libraries that wish to export
> abstract data types must do two things:
> 1. Manage export lists carefully.
> 2. Use role annotations.
>
> A better question might be how to get the word out about the above.
>
> Whether or not `coerce` is "unsafe from a correctness perspective" depends
> on your definition of correctness:
> - If you care only about type safety, then `coerce` is most certainly safe.
> - If you believe that a type's roles are what its author intended, then
> `coerce` is most certainly safe.
> - If you believe that authors may omit critical role annotations and are
> worried about breaking abstraction, then `coerce` is not safe.
>
> There has been some thought about making `coerce`'s behavior different
> with -XSafe than without. See, for example, tickets #8745 (
> https://ghc.haskell.org/trac/ghc/ticket/8745) and #8827 (
> https://ghc.haskell.org/trac/ghc/ticket/8827). In the end, we decided to
> remove this, instead believing authors' role annotations (or lack thereof).
>
> Note that 7.8 does not actually give users a new way to break abstractions
> -- GeneralizedNewtypeDeriving has been around for a while. What 7.8
> provides is a way to break abstractions more easily (`coerce`) and a way to
> prevent this from happening (role annotations).
>
> Richard
>
> On Mar 14, 2014, at 9:22 AM, Brandon Allbery <allbery.b at gmail.com> wrote:
>
> On Fri, Mar 14, 2014 at 9:12 AM, Johan Tibell <johan.tibell at gmail.com>wrote:
>
>> On Fri, Mar 14, 2014 at 2:00 PM, Brandon Allbery <allbery.b at gmail.com>wrote:
>>
>>> On Fri, Mar 14, 2014 at 5:36 AM, Johan Tibell <johan.tibell at gmail.com>wrote:
>>>
>>>> I'm quite worried about this change though. I thought the default role
>>>> for data type was nominal, as that's the safe default. If the default is
>>>> representational, every package author will need to be aware of this
>>>> feature and update their packages. That's quite a high cost.
>>>>
>>>
>>> Nominal default breaks everything that uses newtype deriving and doesn't
>>> have role annotations, doesn't it? Representational default means things
>>> behave in 7.8 as they did in earlier GHCs.
>>>
>>
>> True, but shouldn't coerce be called unsafeCoerce then as it is, in fact,
>> unsafe from a correctness perspective?
>>
>
> My expectation would be that 7.8 keeps the old behavior while enabling the
> new, and possibly issues a warning when newtype deriving is used with no
> role annotations; this gives us a release cycle to get role annotations in
> place before making the new safe behavior default.
>
> --
> brandon s allbery kf8nh                               sine nomine
> associates
> allbery.b at gmail.com
> ballbery at sinenomine.net
> unix, openafs, kerberos, infrastructure, xmonad
> http://sinenomine.net
>  _______________________________________________
> 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/libraries/attachments/20140314/23d81c79/attachment.html>