I think something like that is on the table, at least for a future ghc release. I'm not sure if it made it into the patches for 7.8.1. But this was actually suggested on the relevant ticket last week. (I'm Afk otherwise id dig up the link) On Wednesday, March 26, 2014, Casey McCann wrote:

Were any rules considered along the lines of "Representational by default if all the type's constructors are exported by a module not named 'Internal', nominal by default otherwise"? Better would probably include "exported by a module the package exposes" but that's disgustingly non-local if it's even possible at all. The module name thing is hacky to the extreme but at least it's a simple rule rather than some obscure and opaque heuristics.

Anyway, the goal of something like that would be not so much "figure out what it should be", since that's impossible, but more "default to nominal if and only if there's clear indication the user is already thinking about restricting how the type is used".

Not that I'm really even suggesting such a rule, just wondering if it was discussed.

- C.

...

Hi Mark,

I appreciate your analysis in terms of classes of users -- I think that is helpful for framing the discussion.

About transitivity: I think we're in the clear here. Let's say package A exports types missing role annotations. If package B imports package A and wants to have the full safety afforded by roles, that is no problem whatsoever. Package B has annotations on its types (which may use package A's types) that may restrict certain parameters to be nominal, as appropriate. If package A had role annotations, it's quite possible that package B could omit some annotations (as role inference propagates nominal roles), but there is no problem inherent in this. (Indeed, if package A adds annotations in the future, package B would have redundant, but harmless, annotations.) So, I disagree with Mark's "partially" below -- I think we're fully OK in this regard.

About heuristics: we briefly considered some, though there's no documentation of this anywhere. Specifically, we thought about giving nominal roles to parameters used in class constraints. The problem is, in the actual datatype definition, the constraints tend not to appear? Should we look around for other functions with constraints? That seems likely to be more confusing than helpful. Furthermore, I strongly don't like the idea of using heuristics to infer a feature such as this -- it can cause strange behavior and is hard to specify.

Richard

On Mar 25, 2014, at 11:09 AM, Mark Lentczner wrote:

Thank you to everyone who has been helping me understand this issue in greater depth.

tl;dr: As long as we don't expect any libraries beyond to core to annotate, I'm cool. This presumes that the extra safety isn't, in practice, dependent on transitive adoption by libraries. It also implies that representational is the only possible default, and that there can be no migration from it.

My approach to thinking about this is guided by thinking about supporting an eco-system with 1000s of libraries (hackage), a few dozen of which are heavily promoted (the platform), and a small set that are closely tied to the compiler (the core). The availability, speed of release, motivation, and even skill of the the developers varies widely over that range.

I also think about the various "stances" of different developers:

End developer: makes use of libraries, but just builds apps Internal developer: makes libraries for internal use in a project Casual library writer: makes libraries, primarily for their own needs, but distributed on hackage Popular library writer: actively maintains libraries which are widely used Core library writer: maintainer of a core package that stays in lock step with the compiler

Then, I think about, for each of these, what is the effect on a new feature on them, their existing code, and future code? Does it affect them only if they are using the feature? If they aren't using the feature? For library writers, how does the feature affect clients? If a client wants to use a feature, under what conditions does the library need to do something? This last issue of the "transitivity" the feature is often the biggest concern.

Given that... onto type roles:

The default of representational is the only option, because a default of nominal would require far too many developers to have to update their code. I don't believe that we can ever migrate to nominal as default.

The feature implies that any abstract data type that uses a type

...

in certain ways needs annotate to get the full safety afforded now afforded. However, without annotation, the data type is still no worse off than it was before (there is added safety, but not perhaps relevant to the stand

...

of the library writer). Further, this (pre-existing) non-safety isn't

On Tue, Mar 25, 2014 at 7:23 PM, Richard Eisenberg wrote: parameter point likely

...

a huge concern. Making sure the docs take the tone that most developers need to nothing, and when developers need to be concerned seems like an important way to ensure the right outcome.

A key question here is transitivity: Is it possible for module A to not annotate a type, and then have module B b>

---

...

Libraries mailing list Libraries@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org javascript:; http://www.haskell.org/mailman/listinfo/libraries