Proposal: GHC.Generics marked UNSAFE for SafeHaskell

[Ganesh Sittampalam]

Hi,

On 07/10/2013 04:14, Ryan Newton wrote:
> 
> On Sun, Oct 6, 2013 at 6:28 PM, Ganesh Sittampalam <ganesh at earth.li
> <mailto: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...

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