Re: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

newer
Re: Proposal: GHC.Generics marked...

older
FW: [Haskell-cafe] Poll & plea:...

Ryan Newton

6 Oct 2013 6 Oct '13

11:14 p.m.

On Sun, Oct 6, 2013 at 6:28 PM, Ganesh Sittampalam 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 detailshttp://www.cs.indiana.edu/~rrnewton/papers/2013_07_LVish_quasiDet_working_dr...), 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

Attachments:

attachment.html (text/html — 2.8 KB)

Show replies by date

John Lato

7 Oct 7 Oct

1:13 a.m.

New subject: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

On Sun, Oct 6, 2013 at 10:14 PM, Ryan Newton wrote:

...

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

Ryan Newton

1:19 a.m.

New subject: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

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 wrote:

...

On Sun, Oct 6, 2013 at 10:14 PM, Ryan Newton wrote:

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

Carter Schonwald

1:23 a.m.

New subject: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

ooo, thats illuminating. thanks for cooking that up On Mon, Oct 7, 2013 at 1:13 AM, John Lato wrote:

...

On Sun, Oct 6, 2013 at 10:14 PM, Ryan Newton wrote:

...
On Sun, Oct 6, 2013 at 6:28 PM, Ganesh Sittampalam 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 ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

Carter Schonwald

1:31 a.m.

New subject: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

i assume https://github.com/JohnLato/safe-bugtest/blob/master/Main.hs#L13should say putStrLn "Should print \"Pos (2)\"" rather than -2? On Mon, Oct 7, 2013 at 1:23 AM, Carter Schonwald

...

wrote:

...

ooo, thats illuminating.

thanks for cooking that up

On Mon, Oct 7, 2013 at 1:13 AM, John Lato wrote:

...
On Sun, Oct 6, 2013 at 10:14 PM, Ryan Newton wrote:

...
On Sun, Oct 6, 2013 at 6:28 PM, Ganesh Sittampalam 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 ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

John Lato

2:05 a.m.

New subject: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

Well, no. Presumably the example shouldn't compile at all. That message is more an indication that the demonstration is working as intended. On Mon, Oct 7, 2013 at 12:31 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...

i assume https://github.com/JohnLato/safe-bugtest/blob/master/Main.hs#L13should say putStrLn "Should print \"Pos (2)\""

rather than -2?

On Mon, Oct 7, 2013 at 1:23 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...
ooo, thats illuminating.

thanks for cooking that up

On Mon, Oct 7, 2013 at 1:13 AM, John Lato wrote:

...
On Sun, Oct 6, 2013 at 10:14 PM, Ryan Newton wrote:

...
On Sun, Oct 6, 2013 at 6:28 PM, Ganesh Sittampalam 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 ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

John Lato

2:18 a.m.

New subject: Proposal: GHC.Generics marked UNSAFE for SafeHaskell

Also, I'm not really sure this is a bug, per se. In my opinion when you allow for some sort of generic operations (whether via GHC.Generics or Data), it's roughly equivalent to exporting all the constructors. I don't see how it would work otherwise. But since there's precedent for Typeable, maybe Generics should be restricted in SafeHaskell as well. On Mon, Oct 7, 2013 at 1:05 AM, John Lato wrote:

...

Well, no. Presumably the example shouldn't compile at all. That message is more an indication that the demonstration is working as intended.

On Mon, Oct 7, 2013 at 12:31 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...
i assume https://github.com/JohnLato/safe-bugtest/blob/master/Main.hs#L13should say putStrLn "Should print \"Pos (2)\""

rather than -2?

On Mon, Oct 7, 2013 at 1:23 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:

...
ooo, thats illuminating.

thanks for cooking that up

On Mon, Oct 7, 2013 at 1:13 AM, John Lato wrote:

...
On Sun, Oct 6, 2013 at 10:14 PM, Ryan Newton wrote:

...
On Sun, Oct 6, 2013 at 6:28 PM, Ganesh Sittampalam 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 ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs

4244

Age (days ago)

4244

Last active (days ago)

List overview

Download

6 comments

3 participants

participants (3)

Carter Schonwald
John Lato
Ryan Newton