Generalized Newtype Deriving not allowed in Safe Haskell

[Richard Eisenberg]

On Apr 12, 2015, at 9:51 AM, David Terei <dave.terei at gmail.com> wrote:
> 
> Ideally I'd like to find a way forward that works for everyone and
> isn't just a Safe Haskell mode setting.

Agreed. I'm not convinced this can be done, but it's certainly worth trying.

> 
> I think the first question is, are there situations where you'd want
> to use `coerce` internally to a module but disallow it externally? The
> role mechanism is a little awkward as it doesn't allow this (although
> it does for newtype's). If yes, then I think we should start there.

Yes, the ability to use `coerce` within one module but not elsewhere would be nice. This can currently be simulated (without too much difficulty) with newtypes. A datatype D can have a more permissive role signature than an equivalent newtype N (where `newtype N = MkN D`). The package then exports N (without its constructor). This effectively allows local uses of `coerce`, even for datatypes. A more direct mechanism would be better, but I don't think we should bend over backwards for it.

> 
> If it seems we don't need external vs internal control, then we could
> simply change the default to be that GHC sets referential type
> parameters to nominal and allows them to be weakened to referential
> through role annotations. We could use hackage to test how much
> breakage this would cause.

I worry that the breakage would be significant. But, now that authors have had a chance to put in role annotations, maybe it wouldn't be so bad. The change to GHC to make this happen is trivial: just change default_role in TcTyDecls.initialRoleEnv1. I don't have the infrastructure around to make an all-of-Hackage test, but I'm happy to support someone else who does.

Richard