We need to add role annotations for 7.8

[Richard Eisenberg]

While I see where your discomfort is coming from, this same argument could be said about GeneralizedNewtypeDeriving. I suppose the answer is "yes" -- the goal is for library authors to add role annotations in the future. There is no way to infer what roles are appropriate to preserve the right level of abstraction. Note that this goal would stand regardless of the decision around default roles. Until then, we will have to use `coerce` carefully. After all, `coerce` is only an optimization -- it isn't meant to provide a feature that is otherwise impossible to implement.

Richard

On Mar 14, 2014, at 10:26 AM, Johan Tibell <johan.tibell at gmail.com> wrote:

> 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/9059c7c8/attachment-0001.html>