Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

Hi, On 07/10/2013 04:14, Ryan Newton wrote:

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

What actually happens if you take off the annotation?

My argument is more that it is a violation in spirit to write bad Generic instances that in turn lead to bad fromRep and toRep conversions. (In a similar way to bad Typeable insteances leading to bad type conversions).

I think the problem with "in spirit" arguments is that different people will have different views on what should be safe or not. With a clearly defined set of properties that SafeHaskell does enforce - and by implication nothing else - everyone knows where they stands. Making LVish work seems like a a worthy goal, and I can see a general case for having guaranteed-correct Eq and Ord instances. I wonder if there's anything to be shared with Conal Elliott's unamb, which I think also has some unchecked safety requirements: http://conal.net/blog/posts/merging-partial-values

Second, the usage intent of GHC.Generics as far as I can see, is that users 99.9% of the time will be using -XDeriveGeneric.

I don't think that's entirely true; if you want to get data abstraction then you really would need to define your own instances. Forcing people to give up on their data abstraction actually goes against one of the properties of SafeHaskell above (in spirit :-).

I also understand that you want to require 'standard' Generic instances on types - will that mean that module authors are forced to expose internals to use your library?

Great point! My intent was to short-circuit that by providing "TrustWorthy" SafeEq and SafeOrd instances for standard types.

That doesn't help for arbitrary user-written types though, does it? Ganesh