newtype coercion wrapping status

[Richard Eisenberg]

OK -- thanks for clarifying. This all sits better with me.

But, I'm still a little concerned about the "Safe Haskell" implications. My understanding is that allowing coercions when the constructor is not exported will not be considered "Safe". Here's a way forward:

Currently: a type is considered abstract when its constructors are not exported.

Future proposal: a type is considered abstract when its constructors are not exported AND its type parameters are all at role Nominal.

Under this new definition of "abstract", a library writer that remembers not to export a constructor but neglects to use a role annotation should consider a type *not* to be abstract. Is this what we want?

Richard

On Sep 7, 2013, at 1:16 PM, Simon Peyton-Jones <simonpj at microsoft.com> wrote:

> 
> | In the current code, the
> |         instance Coercible a b => Coercible (T a) (T b)
> | is available for both data and newtypes, if T’s type argument has
> | Representational role, but independent of any constructor presence. See
> | the note at
> | https://github.com/nomeata/ghc/compare/ntclass-clean#L9R1902
> | for a concise and complete list of the conditions for a Coercible
> | instance.
> 
> Right! I explained that badly the first time; thanks for clarifying Joachim.
> 
> So newtype and data behave alike, except that newtype has the *additional* property that if its constructor is available you can coerce to the representation type.  
> 
> | If I understood Simon’s last suggestion correctly than exporting a type
> | constructor with a non-Nominal role means “I am fine if you cast this
> | argument”. If this is not desired (e.g. maybe Ptr a is an example here),
> | then the library author has to annotate the type argument as Nominal.
> 
> Yes, that's right.  In theory someone could want the coercible instance *plus* the nominal role, or vice versa, but I think we can jump that bridge if we come to it.
> 
> Simon
>