Proposal: GHC.Generics marked UNSAFE for SafeHaskell

[Ryan Newton]

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 <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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20131007/a752b434/attachment.html>