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