<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><i>Apologies</i><br></div><div class="gmail_quote">On Tue, Mar 25, 2014 at 8:47 AM, Simon Peyton Jones <span dir="ltr"><<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>></span> wrote:<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">The situation today is that<br>· A client of a library can use GND to do bad things to the library (e.g. change the “key” type of (Map key value)).<br>
· Role annotations allow the library author to prevent that happening.<br>Would you say that means that we are “compelled to suggest to library writers that they annotate”?<br></blockquote><div><br></div><div>Well... I don't think we should.</div>
<div><br></div><div>The reason is that this situation is very sad for it puts the burden upon the library writer, for potential abuse of an extension to Haskell she might not even be aware of! She writes a perfectly safe, reasonable abstracted type, and bam, now has to worry about a very hard to understand situation involving the interaction to two separate Haskell extensions. And furthermore, adding that protection requires yet a third (CPP), and makes the "protection" often as long as the abstract type itself.</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">Looking further ahead, when you say that “there can be no migration from representational-by-default”, do you have data to support that? Notably, any client not using GND could not observe a change. So simply seeing how many library modules use GND would be an upper bound on how many libraries would fail to compile you were to ask us to change the default. Is that 1% of Hackage modules? 10%? 0.1%? I don’t know.</blockquote>
<div><br></div><div>You are wrong that use of GND is the upper bound: The burden is on the type author, not the GND user. And so, while only a small percent of Hackage uses GND (though I note that more and more literature promotes GND (very handy in Shake, for example)...) in order to keep them from breaking, a potentially much larger percentage of Hackage has to get fixed.</div>
<div><br></div><div>What's more, the ability to remedy the situation is in the wrong place: If the default changes, and my GND library breaks, all my users are broken, and worse, I can't do anything about it until I compel the libraries I depend on to annotate.</div>
<div><br></div><div>This is why we can't ever change the default.<br></div><div> </div><div><br></div><div>On Tue, Mar 25, 2014 at 4:23 PM, Richard Eisenberg <span dir="ltr"><<a href="mailto:eir@cis.upenn.edu" target="_blank">eir@cis.upenn.edu</a>></span> wrote:<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">The problem is, in the actual datatype definition, the constraints tend not to appear? Should we look around for other functions with constraints?</blockquote>
</div><div><br></div><div>Right - we've been advocating removing them for years, and only placing the constraints on the functions that need them, since they really present no constraint on the data type itself. Of course, the presence of GND and roles means that they now <i>would be</i> saying something about the type - as they are indicating that the integrity of the type requires the constraint. So yes, a shift to using this as the marker for nominal would require a change in developer habit. But so does annotation.</div>
<div><br></div><div>I agree that other heuristics are pretty fragile: names of modules, presence of constraints in functions, and even status of constructor export are all a) far too removed from the code site in question, and b) things that are much more fluid during development. I would be against any of these.</div>
<div><br></div><div><div class="gmail_quote"><br class="">On Wed, Mar 26, 2014 at 8:46 PM, Edward Kmett <span dir="ltr"><<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>></span> wrote:<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 dir="ltr">Personally, looking at it 10 years on, having a nominal default would look pretty terrible to me. <div>I'd be stuck annotating everything I write. Nothing easy could just be easy. </div></div></blockquote>
<div><br></div><div>Agree whole-heartedly. <br></div></div></div><div>Worth reiterating: Easy things should not need annotation.</div><div><br></div><div><div class="gmail_quote"><br class="">On Wed, Mar 26, 2014 at 11:44 PM, Ganesh Sittampalam <span dir="ltr"><<a href="mailto:ganesh@earth.li" target="_blank">ganesh@earth.li</a>></span> wrote:<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 id=":x1" class="" style="overflow:hidden">I think that in theory the basic principle should be that by default you<br>
can only write a GND if you could have written it by hand in the same<br>scope - i.e. you can only do it if you have access to the relevant<br>methods and datatype constructors etc</div></blockquote><div><br></div><div>
This is much closer to the approach I wish had been taken: The burden is on the correct party. The client of the lib, wishing to use it in a new way, unbeknownst to the library author. I don't know enough about the type theory, but could we have disallowed GND in the presence of type families anywhere in the class being derived?</div>
</div><br></div></div></div></div>