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 < [email protected]> 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 < > [email protected]> wrote: > >> ooo, thats illuminating. >> >> thanks for cooking that up >> >> >> On Mon, Oct 7, 2013 at 1:13 AM, John Lato <[email protected]> wrote: >> >>> On Sun, Oct 6, 2013 at 10:14 PM, Ryan Newton <[email protected]> wrote: >>> >>>> >>>> On Sun, Oct 6, 2013 at 6:28 PM, Ganesh Sittampalam <[email protected]>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 >>> [email protected] >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >>> >> >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
