Indeed! That seems to be a direct violation of this language in the manual:
*"An important part of this is that safe compiled code is not able to examine or create data values using data constructors that it cannot import" * And the funny part is that that is unrelated to my particular problem of the user making their own Generic instances and is instead related to simply exposing "to"... Thanks for putting that together. 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
