Proposal: GHC.Generics marked UNSAFE for SafeHaskell

[John Lato]

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 <jwlato at gmail.com> 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 at 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 at gmail.com> wrote:
>>
>>> ooo, thats illuminating.
>>>
>>> thanks for cooking that up
>>>
>>>
>>> On Mon, Oct 7, 2013 at 1:13 AM, John Lato <jwlato at gmail.com> wrote:
>>>
>>>> On Sun, Oct 6, 2013 at 10:14 PM, Ryan Newton <rrnewton at gmail.com>wrote:
>>>>
>>>>>
>>>>> 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...
>>>>>
>>>>
>>>> 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 at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131007/0373db14/attachment-0001.html>