It's in the nature of type systems that as well as excluding bad programs they also exclude some good programs. So if we tighten up the type system (and GND allows seg-faults at the moment) that is certain to exclude some good programs. Would you like a flag to say "allow me to use GeneralisedNewtypeDeriving even if it is dangerous to do so"? Simon From: ghc-devs [mailto:ghc-devs-bounces@haskell.org] On Behalf Of Johan Tibell Sent: 12 October 2013 00:15 To: Richard Eisenberg Cc: Stephanie Weirich; ghc-devs@haskell.org Devs Subject: Re: small improvement to roles mechanism Let me start by saying that I'm happy we're trying to fix the GND problem. Thanks for working on that. 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. On Thu, Oct 10, 2013 at 8:26 PM, Richard Eisenberg mailto:eir@cis.upenn.edu> wrote: 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: from logict-0.2.3/Control.Monad.Logic.Class:

class (MonadPlus m) => MonadLogic m where msplit :: m a -> m (Maybe (a, m a))

from monadLib-3.5.2/MonadLib:

class (Monad m) => ReaderM m i | m -> i where ask :: m i

from base/Control.Arrow:

class Arrow a => ArrowApply a where app :: a (a b c, b) c

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

instance ArrowApply Foo where ...

we check that Foo's first parameter has a representational role. If it doesn't, then the instance is rejected. An alternative, somewhat heavier idea would be to represent roles as class constraints. We could have

class NextParamNominal (c :: k) class NextParamRepresentational (c :: k)

GHC could "generate" instances for every datatype definition. For example:

type role Map nominal representational data Map k v = ...

would induce

instance NextParamNominal Map instance NextParamRepresentational (Map k)

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.) Then, the classes above would just have to add a superclass, like this:

class (Arrow a, NextParamRepresentational a) => ArrowApply a where app :: a (a b c, b) c

The role inference mechanism would be made aware of role constraints and use this one to derive that ArrowApply is OK for GND. 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). 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. Thanks, Richard PS: Due credit is to migmit for suggesting the type-class idea on glasgow-haskell-users. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.orgmailto:ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs