We need to add role annotations for 7.8

[Mark Lentczner]

*Apologies*
On Tue, Mar 25, 2014 at 8:47 AM, Simon Peyton Jones
<simonpj at microsoft.com>wrote:

> The situation today is that
> ·         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)).
> ·         Role annotations allow the library author to prevent that
> happening.
> Would you say that means that we are “compelled to suggest to library
> writers that they annotate”?
>

Well... I don't think we should.

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.

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.


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.

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.

This is why we can't ever change the default.


On Tue, Mar 25, 2014 at 4:23 PM, Richard Eisenberg <eir at cis.upenn.edu>
 wrote:

> The problem is, in the actual datatype definition, the constraints tend
> not to appear? Should we look around for other functions with constraints?


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 *would be* 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.

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.


On Wed, Mar 26, 2014 at 8:46 PM, Edward Kmett <ekmett at gmail.com> wrote:

> Personally, looking at it 10 years on, having a nominal default would look
> pretty terrible to me.
> I'd be stuck annotating everything I write. Nothing easy could just be
> easy.
>

Agree whole-heartedly.
Worth reiterating: Easy things should not need annotation.


On Wed, Mar 26, 2014 at 11:44 PM, Ganesh Sittampalam <ganesh at earth.li>
 wrote:

> I think that in theory the basic principle should be that by default you
> can only write a GND if  you could have written it by hand in the same
> scope - i.e. you can only do it if you have access to the relevant
> methods and datatype constructors etc
>

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20140328/110b7223/attachment.html>