I think a few clarifications might help: - Roles, as originally conceived, were not an attempt to make Unsafe code Safe. Instead, they make unsafe things safe. Before roles, it was quite possible to write Haskell code that would cause a seg fault at runtime. Now, this is (short of unsafeCoerce & friends) impossible, as far as we know. This is independent of any concern with Safe Haskell. That is why certain code that used to work with GND can no longer do so, and why there is no easy fix -- the old code is unsafe, not just Unsafe.
- Role annotations are never necessary to ensure type safety. To reiterate: all Haskell code, with or without type annotations, is now safe from the interaction between GND and TypeFamilies. - The whole debate here is about *abstraction* -- whether or not a user outside of a library can fiddle with that library's expected invariants. - Edward and Mark have said that with a default of a nominal role "Nothing easy could just be easy." Yet, we accept the need for deriving Eq and Show without question. I think, if we ignore its current alienness, a role annotation is on a similar order -- a role annotation (in a world with a nominal default) would be granting new capabilities to users of a type, just like adding instances of classes. - If you could use GND only where the constructors are available, then some valid current use of GND would break, I believe. It would mean that GND would be unable to coerce a (Map String Int) to a (Map String Age), because the constructor of Set is (rightly) not exported. This would have a direct runtime significance for some users -- their code would run slower. Richard On Mar 28, 2014, at 12:17 PM, Mark Lentczner wrote: > Apologies > On Tue, Mar 25, 2014 at 8:47 AM, Simon Peyton Jones <simo...@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 <e...@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 <ekm...@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 <gan...@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? > > _______________________________________________ > Libraries mailing list > librar...@haskell.org > http://www.haskell.org/mailman/listinfo/libraries
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
