Proposal: GHC.Generics marked UNSAFE for SafeHaskell

[Nicolas Frisby]

Ah, I see. I had implicitly assumed we were talking about yet another
"magic" class.

This is snow balling in my head right now, so I'll hold off on further
suggestions. My main concern was the relationship between:

  * an irreducible application of the Derives type family
  * an application that reduces to False
  * an insoluble constraint for the Derives class
On Oct 15, 2013 7:28 AM, "José Pedro Magalhães" <dreixel at gmail.com> wrote:

>
>
>
> On Tue, Oct 15, 2013 at 4:49 AM, Edward Kmett <ekmett at gmail.com> wrote:
>
>> The issue with such an explicit false is that it requires more magic on
>> behalf of the compiler.
>>
>> It would have to be filled in whenever an explicit `instance Eq Blah` was
>> written.
>>
>> Recall that
>>
>> deriving instance Eq Blah
>>
>> can occur after the data type declaration site and may have to be used
>> for many more complicated recursive data types, so it isn't sufficient to
>> fill in at the data type declaration.
>>
>
> Yes, I know. But I don't think this would require _more_ magic than the
> class instances.
> And I don't see how class instances solve the problem; how can the user be
> prevented
> from defining an |instance Derives MyData Eq| if the instance wasn't
> indeed derived? Only
> through compiler magic...
>
> Pedro
>
>
>>
>> -Edward
>>
>>
>> On Mon, Oct 14, 2013 at 11:41 PM, Ryan Newton <rrnewton at gmail.com> wrote:
>>
>>> But what stops the user from defining their own instances if they in
>>> fact did not derive it?
>>>
>>> The explicit "False" in Pedro's formulation seems to serve this purpose.
>>>
>>>
>>>
>>> On Mon, Oct 14, 2013 at 11:20 PM, Nicolas Frisby <
>>> nicolas.frisby at gmail.com> wrote:
>>>
>>>> The formulation as a type family seems to conflict with the open-world
>>>> principle. Would a class-based encoding instead be sufficient?
>>>>
>>>> -- the proposed, special wired-in class
>>>> class Derives (t :: k1) (c :: k2)
>>>>
>>>> -- GHC would infer these from Pedro's example's declarations
>>>> instance Derives MyData Eq
>>>> instance Derives MyData Generic
>>>> instance Derives MyData Show
>>>>
>>>> NB that there is no instance Derives MyData Ord, but standalone
>>>> deriving could yield one "later"
>>>>
>>>> On Mon, Oct 14, 2013 at 10:02 PM, Ryan Newton <rrnewton at gmail.com>wrote:
>>>>
>>>>> Hey, that's an awesome formulation!  Thanks Pedro.
>>>>>
>>>>> Any idea how much work this would be to implement in GHC, if it did
>>>>> garner approval?
>>>>>
>>>>>
>>>>> On Tue, Oct 8, 2013 at 3:48 AM, José Pedro Magalhães <
>>>>> dreixel at gmail.com> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> On Mon, Oct 7, 2013 at 10:32 AM, Dag Odenhall <dag.odenhall at gmail.com
>>>>>> > wrote:
>>>>>>
>>>>>>> Here‘s a thought: doesn’t Generic already have an unused phantom
>>>>>>> type that's only there “just in case we need to add something in the
>>>>>>> future”?
>>>>>>>
>>>>>> No, it doesn't.
>>>>>>
>>>>>> Just a thought: what if we had a type family
>>>>>>
>>>>>> type family Derives (t :: k1) (c :: k2) :: Bool
>>>>>>
>>>>>> which would automatically be instantiated by GHC appropriately? E.g.,
>>>>>> if the user had the following code:
>>>>>>
>>>>>> data MyData = MyData deriving (Eq, Generic)
>>>>>> deriving instance Show MyData
>>>>>> instance Ord MyData
>>>>>>
>>>>>> GHC would automatically instantiate:
>>>>>>
>>>>>> type instance Derives MyData Eq      = True
>>>>>> type instance Derives MyData Generic = True
>>>>>> type instance Derives MyData Show    = True
>>>>>> type instance Derives MyData Ord     = False
>>>>>>
>>>>>> Would this be something Ryan could use for detecting safe instances
>>>>>> for LVish?
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> Pedro
>>>>>>
>>>>>> _______________________________________________
>>>>>> ghc-devs mailing list
>>>>>> ghc-devs at haskell.org
>>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> ghc-devs mailing list
>>>>> ghc-devs at haskell.org
>>>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>>>
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> ghc-devs mailing list
>>> ghc-devs at haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-devs
>>>
>>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20131015/62dad851/attachment.html>