Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

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#L13should 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 wrote:

...

On Sun, Oct 6, 2013 at 10:14 PM, Ryan Newton wrote:

...

On Sun, Oct 6, 2013 at 6:28 PM, Ganesh Sittampalam 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...

How about this demo repo? https://github.com/JohnLato/safe-bugtest

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