Proposal: GHC.Generics marked UNSAFE for SafeHaskell

[Ryan Newton]

On Sun, Oct 6, 2013 at 6:28 PM, Ganesh Sittampalam <ganesh at 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<http://www.cs.indiana.edu/~rrnewton/papers/2013_07_LVish_quasiDet_working_draft.pdf>),
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131006/1f0893dc/attachment-0001.html>