Also, I'm not really sure this is a bug, per se.  In my opinion when you allow for some sort of generic operations (whether via GHC.Generics or Data), it's roughly equivalent to exporting all the constructors.  I don't see how it would work otherwise.

But since there's precedent for Typeable, maybe Generics should be restricted in SafeHaskell as well.


On Mon, Oct 7, 2013 at 1:05 AM, John Lato <jwlato@gmail.com> wrote:
Well, no.  Presumably the example shouldn't compile at all.  That message is more an indication that the demonstration is working as intended.

On Mon, Oct 7, 2013 at 12:31 AM, Carter Schonwald <carter.schonwald@gmail.com> wrote:
i assume https://github.com/JohnLato/safe-bugtest/blob/master/Main.hs#L13 should say 
    putStrLn "Should print \"Pos (2)\""

rather than -2?


On Mon, Oct 7, 2013 at 1:23 AM, Carter Schonwald <carter.schonwald@gmail.com> wrote:
ooo, thats illuminating.

thanks for cooking that up


On Mon, Oct 7, 2013 at 1:13 AM, John Lato <jwlato@gmail.com> wrote:
On Sun, Oct 6, 2013 at 10:14 PM, Ryan Newton <rrnewton@gmail.com> wrote:

On Sun, Oct 6, 2013 at 6:28 PM, Ganesh Sittampalam <ganesh@earth.li> wrote:
 - Referential transparency: e.g. no unsafePerformIO
 - Module boundary control: no abstraction violation like Template
Haskell and GeneralizedNewtypeDeriving
 - Semantic consistency: importing a safe module can't change existing
code, so no OverlappingInstances and the like
Is this change necessary to preserve the existing properties, or are you
hoping to add a new one?

I'm not currently aware of ways to break these invariants *just* with GHC.Generics.  Hmm, but I would like to know why it is marked trustworthy and not inferred-safe...

I'm really not a safe haskell expert, but I believe this is a demonstration of using GHC.Generics to violate a module's abstraction boundaries with SafeHaskell enabled.

If I'm incorrect, I would appreciate if somebody could explain my error.  If, however, I'm correct, then I think that Ryan's proposal of marking GHC.Generics Unsafe is the best way to remedy the problem.

A possible stumbling block may involve base and package-trust, but I'm not certain of the current status.

John L.

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