<div dir="ltr">On Sat, Oct 12, 2013 at 8:00 AM, Simon Peyton-Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-GB" link="blue" vlink="purple">
<div>
<p style="margin-right:0cm;margin-bottom:6pt;margin-left:35.7pt"><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)"><span><br>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span style="font-size:11pt;font-family:Verdana,sans-serif;color:rgb(31,73,125)">The current proposal, which I am happy with, is to
<i>express the answer to this question in T’s role annotation</i>. There is design wiggle-room here:<u></u><u></u></span></p>
<p style="margin-right:0cm;margin-bottom:6pt;margin-left:72pt">
<u></u><span style="font-size:11pt;font-family:'Courier New';color:rgb(31,73,125)"><span>o<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span style="font-size:11pt;font-family:Verdana,sans-serif;color:rgb(31,73,125)">If there is no user-supplied annotation, what should the default be? The inferred (lease-restrictive) role, or the Nominal
(most restrictive) role? <u></u><u></u></span></p>
<p style="margin-right:0cm;margin-bottom:6pt;margin-left:72pt">
<u></u><span style="font-size:11pt;font-family:'Courier New';color:rgb(31,73,125)"><span>o<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span style="font-size:11pt;font-family:Verdana,sans-serif;color:rgb(31,73,125)">How expressive is the role annotation language, especially where type constructors are concerned?<u></u><u></u></span></p>
<p class="" style="margin-right:0cm;margin-bottom:6pt;margin-left:36pt">
<span style="font-size:11pt;font-family:Verdana,sans-serif;color:rgb(31,73,125)">So the design is not fully stable here, but I think the principle, that T’s role ascription answers the question, is sound.<u></u><u></u></span></p>
<p style="margin-right:0cm;margin-bottom:6pt;margin-left:36pt">
<u></u><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span style="font-size:11pt;font-family:Verdana,sans-serif;color:rgb(31,73,125)">The current, fairly inexpressive role annotation language makes three Hackage packages (a tiny number) fail to compile
because their use of GND is rejected. They have fairly few dependencies, so in all 18 packages break. Each of the three can be fixed with very modest changes. This does not sound like a lot of pain to me.</span></p></div>
</div></blockquote><div><div>It also currently means that any sort of transformer or composition infers as having a nominal role for its arguments. This rather greatly reduces the applicability of Coercible. The suggestion Richard made at the start of this thread starts to hint at how we might get something that lacks these limitations. It might be good to have some time to explore this corner of the design space without the looming thread of imminent release.</div>
</div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><p style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
</p></div></blockquote></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple">
<div><p style="margin-right:0cm;margin-bottom:6pt;margin-left:36pt"><span style="font-size:11pt;font-family:Verdana,sans-serif;color:rgb(31,73,125)">That said, if you think it best, I’d be perfectly happy to make GND failure into a warning for one release cycle. (I wouldn’t do that myself, but I’m
quite willing to be guided on this one.)</span></p></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div lang="EN-GB" link="blue" vlink="purple"><div><p style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm"><span style="font-size:11pt;font-family:Verdana,sans-serif;color:rgb(31,73,125)">In short:<u></u><u></u></span></p>
<p style="margin-right:0cm;margin-bottom:6pt;margin-left:36pt">
<u></u><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span style="font-size:11pt;font-family:Verdana,sans-serif;color:rgb(31,73,125)">Coercible is opt-in anyway<u></u><u></u></span></p>
<p style="margin-right:0cm;margin-bottom:6pt;margin-left:36pt">
<u></u><span style="font-size:11pt;font-family:Symbol;color:rgb(31,73,125)"><span>·<span style="font-style:normal;font-variant:normal;font-weight:normal;font-size:7pt;line-height:normal;font-family:'Times New Roman'">
</span></span></span><u></u><span style="font-size:11pt;font-family:Verdana,sans-serif;color:rgb(31,73,125)">If you prefer, GND failure can be a warning<u></u><u></u></span></p>
<p class="" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<span style="font-size:11pt;font-family:Verdana,sans-serif;color:rgb(31,73,125)"></span></p></div></div></blockquote>I am perhaps a bit over-cautious, but I'd feel much more comfortable with the GND failure as a warning for a release cycle. That gives end users a year to get their code in order. GND is the kind of thing used more by folks writing applications than in library code, so I am somewhat concerned that the Hackage summary may be optimistic, so I'm inclined to tread cautiously here.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">From a release management standpoint folks with a short maintenance window would then be able to write code with role annotations by 7.10 so that their code would work with 7.8 and 7.10, and users with longer maintenance windows could put in the CPP pragmas necessitated by this change, and it buys us breathing room to see if Richard's suggestion can be adapted to get something that gives us more of the power of full on role parametricity without having to change the typechecker.<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple"><div><br></div>
<div><span style="color:rgb(31,73,125);font-family:Verdana,sans-serif;font-size:11pt">What’s not to like? Am I missing anything?</span><br></div>
<p class="" style="margin-right:0cm;margin-bottom:6pt;margin-left:0cm">
<span style="font-size:11pt;font-family:Verdana,sans-serif;color:rgb(31,73,125)"></span></p></div></blockquote><div><div>As it stands, all roles do for me now is break code that previously worked, and infer constraints that are too tight to let Coercible be useful for anything but trivial examples. Both of these issues seem addressable, but if we lock in the current solution I fear we'll get stuck in a local optimum, with a much better solution just over the hill.</div>
</div><div><br></div><div>-Edward</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div lang="EN-GB" link="blue" vlink="purple">
<div><div style="border-style:none none none solid;border-left-color:blue;border-left-width:1.5pt;padding:0cm 0cm 0cm 4pt"><div><div style="border-style:solid none none;border-top-color:rgb(225,225,225);border-top-width:1pt;padding:3pt 0cm 0cm">
<p class=""><b><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif">From:</span></b><span lang="EN-US" style="font-size:11pt;font-family:Calibri,sans-serif"> ghc-devs [mailto:<a href="mailto:ghc-devs-bounces@haskell.org" target="_blank">ghc-devs-bounces@haskell.org</a>]
<b>On Behalf Of </b>Richard Eisenberg<br>
<b>Sent:</b> 12 October 2013 03:20<br>
<b>To:</b> Edward Kmett<br>
<b>Cc:</b> Stephanie Weirich; Joachim Breitner; <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a> Devs</span></p><div class="im"><br>
<b>Subject:</b> Re: small improvement to roles mechanism<u></u><u></u></div><p></p>
</div>
</div>
<p class=""><u></u> <u></u></p>
<div>
<p class="">I tend to agree with the above remarks and have been silencing the little voice in the back of my head that has suggested we pull roles out of 7.8. Ever since the debate about default roles vis-a-vis abstract datatypes started, I've been
wondering if we're being a little hasty here.<u></u><u></u></p>
</div><div><div class="h5">
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">As we think about how to proceed, I think it's worth teasing apart the two different strains in all of this: enforcing type safety and enforcing abstraction.<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">Roles, as they are, do a quite good job of enforcing type safety. When compiling all of Hackage, the majority of the breakage from roles was due to real type goofs in programs. A total of 18 packages (out of the 3,234 that compile with
7.6.3) fail to compile because of deficiencies in the role system, including transitive breakage (i.e., packages that depend on broken packages). A small change in the GND check discussed in this forum would fix 11 of these, leaving only 7. Given that type
systems are necessarily conservative, I'm not too displeased with this result -- the 3 packages that would need to be changed would require only a few lines of code. Given this result, I disagree with Edward's claim that roles will provide the biggest pain
in upgrading from 7.6 to 7.8.<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">That said, I of course would like to do better and would prefer to 0 broken packages due to deficiencies in the role system.<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">On the other hand, roles as they are do a poor job of enforcing abstraction. But, before roles came along, there wasn't anything resembling a way of enforcing abstraction in the context of GND. So, this isn't exactly a new problem. The
only thing (I think) exacerbating the problem is that Coercible now makes it easier than ever to break abstraction.<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">That said, I of course would like to fix this problem, too.<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">So, how to proceed? There are a few options:<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">1. I'll change the GND check to be a little more liberal, and we release roles in 7.8. I could notify the authors of the three packages that need to be updated because of the lack of role abstraction.<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">2. Like #1, but disallow Coercible. This way, the abstraction problem is no worse than it was before. (Apologies to Joachim if he minds this suggestion.)<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">3. Pull roles out of 7.8, giving us a little more time to Get It Right.<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">It's a little hard for me to choose between these options, but I think it's good to be conservative in language design of a language in real use, so I lean slightly toward option #3. Doing this is very feasible from a technical standpoint
-- it's easy to turn off the checks.<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">If we go with #3, given the flux in the design, I'm even uncertain about the idea of warnings in 7.8. It would all feel a little silly if we issue these warnings and then change the design between 7.8 and 7.10 just enough to make the warnings
wrong. I think warnings in 7.8.2 is a better idea.<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">As for Johan's remark that the feature should have been vetted more thoroughly -- I completely agree, and I'll take responsibility for that decision. I did do some ad-hoc testing against packages on Hackage known to use GND, but the testing
was not as thorough as it could have been. That said, I'm not sure anything would have played out too differently had I done more extensive testing; the results were about as I expected.<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">I do greatly appreciate everyone's feedback and interest in this!<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">Richard<u></u><u></u></p>
</div>
<p class=""><u></u> <u></u></p>
<div>
<div>
<p class="">On Oct 11, 2013, at 7:55 PM, Edward Kmett wrote:<u></u><u></u></p>
</div>
<p class=""><br>
<br>
<u></u><u></u></p>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<p class="">I have to agree that I'm somewhat disturbed by the fact that we're pushing this out and we're still finding issues with it this close to release. =(<u></u><u></u></p>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">It strikes me that the role machinery is going to be the cause of the majority of the pain users have upgrading to 7.8, and if I try to pretend to be Mark Lentczner for a bit, it makes it seem highly likely that it'd be the kind of thing
that keeps 7.8 from going into a Haskell Platform, causing the groundhog to see his shadow, leaving us with another year of 7.4 or 7.6.x.<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">I know we're at the 5 yard line, but to metaphorically throw a bunch of metaphors in a blender, if we had to make the uncomfortable decision to perform triage and ask if it should be put off (at least enforcing) the roles machinery to 7.10,
so we can know we have it right, how much fallout would there be? Off the top of my head, of course Joachim's work on Coercible would be affected. What else?<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">One option might be to pull the teeth of role inference for 7.8 with regards to GND, and turn bad roles use into a warning for a release cycle. That would give the community a year to get role annotations in place before generalized newtype
deriving for their code just stopped working.<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<div>
<p class="">If we ship with this the way it stands, I don't foresee the community reaction being good.<u></u><u></u></p>
</div>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">With its teeth pulled, then GND could proceed as before, but with the added detailed warnings from the dictionary coercions helping to guide folks to make the change. By the time we'd be enforcing correct role annotations most folks would
have them in place to silence the warnings.<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">-Edward<u></u><u></u></p>
</div>
</div>
<div>
<p class="" style="margin-bottom:12pt"><u></u> <u></u></p>
<div>
<p class="">On Fri, Oct 11, 2013 at 7:15 PM, Johan Tibell <<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="">Oh and let me add: it would have been nice to have the people actually making these change to have done an impact analysis on Hackage, instead of discovering potential issues a week or two before the release. Lets try to do that next time.<u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="" style="margin-bottom:12pt"><u></u> <u></u></p>
<div>
<p class="">On Fri, Oct 11, 2013 at 4:14 PM, Johan Tibell <<a href="mailto:johan.tibell@gmail.com" target="_blank">johan.tibell@gmail.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="">Let me start by saying that I'm happy we're trying to fix the GND problem. Thanks for working on that.<u></u><u></u></p>
<div>
<p class=""><u></u> <u></u></p>
</div>
<div>
<p class="">That being said: is this ready for mainstream consumption? We're forcing this on everyone without any language pragma or flags to opt-in/out. That is bad if we're not sure we're doing the right thing in some cases or if we're causing spurious
failures. At ICFP I got the impression that very few people will be affected, but Bryan's result suggests there are more people than I thought.<u></u><u></u></p>
</div>
<div>
<p class=""><u></u> <u></u></p>
</div>
</div>
<div>
<div>
<div>
<p class="" style="margin-bottom:12pt"><u></u> <u></u></p>
<div>
<p class="">On Thu, Oct 10, 2013 at 8:26 PM, Richard Eisenberg <<a href="mailto:eir@cis.upenn.edu" target="_blank">eir@cis.upenn.edu</a>> wrote:<u></u><u></u></p>
<blockquote style="border-style:none none none solid;border-left-color:rgb(204,204,204);border-left-width:1pt;padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<p class="">In Bryan's recent test of GHC 7.8 against all of Hackage, there were three spurious errors caused by lack of role abstraction. Here are the class definitions where a nominal parameter is inferred, probably against the wishes of the author:<br>
<br>
from logict-0.2.3/Control.Monad.Logic.Class:<br>
> class (MonadPlus m) => MonadLogic m where<br>
> msplit :: m a -> m (Maybe (a, m a))<br>
<br>
from monadLib-3.5.2/MonadLib:<br>
> class (Monad m) => ReaderM m i | m -> i where<br>
> ask :: m i<br>
<br>
from base/Control.Arrow:<br>
> class Arrow a => ArrowApply a where<br>
> app :: a (a b c, b) c<br>
<br>
In each of these, the last parameter of the class is given a nominal role because it appears as the parameter of a type variable. However, in each case, it appears as the parameter of a *class* type variable. This means that, if we somehow knew that the class
author wanted the class to be usable with GND, we could simply check every instance declaration for that class to make sure that the relevant concrete instantiation has the right role. For example, when the user writes, for example<br>
<br>
> instance ArrowApply Foo where …<br>
<br>
we check that Foo's first parameter has a representational role. If it doesn't, then the instance is rejected.<br>
<br>
An alternative, somewhat heavier idea would be to represent roles as class constraints. We could have<br>
<br>
> class NextParamNominal (c :: k)<br>
> class NextParamRepresentational (c :: k)<br>
<br>
GHC could "generate" instances for every datatype definition. For example:<br>
<br>
> type role Map nominal representational<br>
> data Map k v = …<br>
<br>
would induce<br>
<br>
> instance NextParamNominal Map<br>
> instance NextParamRepresentational (Map k)<br>
<br>
Users would not be able to write these instances -- they would have to be generated by GHC. (Alternatively, there could be no instances, just a little magic in the constraint solver. Somewhat like Coercible.)<br>
<br>
Then, the classes above would just have to add a superclass, like this:<br>
<br>
> class (Arrow a, NextParamRepresentational a) => ArrowApply a where<br>
> app :: a (a b c, b) c<br>
<br>
The role inference mechanism would be made aware of role constraints and use this one to derive that ArrowApply is OK for GND.<br>
<br>
This "heavier" approach has a similar upshot to the first idea of just checking at instance declarations, but it is more customizable and transparent to users (I think).<br>
<br>
<br>
I'm not sure I'm advocating for this change (or volunteering to implement before the release candidate), but I wanted to document the idea and get any feedback that is out there. This would fix the breakage we've seen without totally changing the kind system.<br>
<br>
Thanks,<br>
Richard<br>
<br>
PS: Due credit is to migmit for suggesting the type-class idea on glasgow-haskell-users.<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><u></u><u></u></p>
</blockquote>
</div>
<p class=""><u></u> <u></u></p>
</div>
</div>
</div>
</blockquote>
</div>
<p class=""><u></u> <u></u></p>
</div>
</div>
</div>
<p class="" style="margin-bottom:12pt"><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/ghc-devs" target="_blank">http://www.haskell.org/mailman/listinfo/ghc-devs</a><u></u><u></u></p>
</blockquote>
</div>
<p class=""><u></u> <u></u></p>
</div>
</blockquote>
</div>
<p class=""><u></u> <u></u></p>
</div></div></div>
</div>
</div>
</blockquote></div><br></div></div>