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

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).

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.

Third, without making this change I know of no way to provide safe/correct Eq and Ord instances in a way that extends to user datatypes. And in LVish we have one example of what I think could be a valuable Safe-Haskell compliant parallel programming library (see the POPL'14 paper for more details), but which will never be fully water-tight without vetted Eq and Ord instances.

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.

If you know any better ways to go forward, let me know!

Also, if anyone uses SafeHaskell with non-derived Generic instances, please speak up!

Cheers,

-Ryan