Proposal: GHC.Generics marked UNSAFE for SafeHaskell

Carter Schonwald carter.schonwald
Mon Oct 7 05:23:58 UTC 2013


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/c55862c0/attachment.html>




More information about the Libraries mailing list