Hi David,

Joachim, Simon, and I have been trying to figure out how roles and newtype 
coercions fit in with Safe Haskell. (See, for example 
http://www.haskell.org/pipermail/ghc-devs/2013-September/002526.html, which I 
will try to summarize here.)

It all boils down to this: Does Safe Haskell strive to guarantee that a 
datatype whose constructors are not visible is actually abstract?

With roles implemented, GeneralizedNewtypeDeriving (GND) and the newtype 
coercions (implemented through a Coercible "class") are fully type-safe. 
However, there are various ways of using these features to end-run abstraction. 
I infer from #5498 that Safe Haskell *does* strive to maintain abstraction 
barriers, and then we need to think hard about how to fit GND and Coercible 
into Safe Haskell. Bug #5498 demonstrates how GND breaks abstraction (this 
behavior is unchanged with roles), and here is an example of how Coercible can, 
too:

> module A (Abstract) where
> data Abstract a = MkAbs a
>
> abstractInt :: Int -> Abstract Int
> abstractInt = MkAbs
>
------
> module B where
> import A
> import GHC.Prim  -- or wherever Coercible lives
>
> newtype Age = MkAge Int
> notSoAbstract :: Abstract Age
> notSoAbstract = coerce (abstractInt 5)

Does this behavior eliminate the use of `coerce` within Safe Haskell? Does 
#5498 eliminate GND from Safe Haskell? And, do the fixes proposed in the email 
thread linked above fix these problems? To wit, under Safe Haskell, we propose 
that coercions and GND work only when all constructors of the relevant datatype 
(and, recursively, all constructors of datatypes mentioned in the top-level 
datatype, going all the way down) are visible.

Thanks,
Richard
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Reply via email to