Proposal: GHC.Generics marked UNSAFE for SafeHaskell

José Pedro Magalhães dreixel at gmail.com
Tue Oct 15 12:28:34 UTC 2013


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


More information about the ghc-devs mailing list