Opened 3 years ago

Closed 3 years ago

Last modified 20 months ago

#12245 closed bug (fixed)

Deriving Data at higher kinds

Reported by: simonpj Owned by: simonpj
Priority: normal Milestone:
Component: Compiler Version: 8.0.1
Keywords: QuantifiedConstraints Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: deriving/should_compile/T12245
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Here's what Lennart Spitzner wanted to do:

> {-# LANGUAGE StandaloneDeriving #-}
> {-# LANGUAGE DeriveDataTypeable #-}
> {-# LANGUAGE FlexibleInstances #-}
> 
> import Data.Data ( Data )
>
> data Foo f = Foo (f Bool) (f Int)
> 
> deriving instance Data (Foo [])
> deriving instance Data (Foo Maybe)

Of course you can't derive Data for Foo because we don't know what f is, so Lennart is making multiple instances, one for each instance of f. It's a bit clumsy. What we would really like is

deriving instance (forall a. Data  => Data (f a)) => Data (Foo f)

but we don't have higher order instances yet! So Lennart is manually making two instances.

This should work, but he gets

> Main.hs: line 45, column 1:
>   Multiple declarations of ‘$cr2C’
>     Declared at: Main.hs:44:1
>                  Main.hs:45:1
> Main.hs: line 45, column 1:
>   Multiple declarations of ‘$tr2D’
>     Declared at: Main.hs:44:1
>                  Main.hs:45:1

Change History (7)

comment:1 Changed 3 years ago by goldfire

Adding implication (quantified) constraints seems to be the answer to the underlying problem. See #2256.

comment:2 Changed 3 years ago by simonpj

Owner: set to simonpj

comment:3 Changed 3 years ago by Simon Peyton Jones <simonpj@…>

In 895eefa8/ghc:

Make unique auxiliary function names in deriving

In deriving for Data, we make some auxiliary functions, but they
didn't always get distinct names (Trac #12245).  This patch fixes
it by using the same mechanism as for dictionary functions, namely
chooseUniqueOccTc.

Some assocated refactoring came along for the ride.

comment:4 Changed 3 years ago by simonpj

Resolution: fixed
Status: newclosed
Test Case: deriving/should_compile/T12245

The presenting bug is fixed. I agree that #2256 is a better solution, but it's much further off. Meanwhile I'll close this.

comment:5 Changed 3 years ago by lspitzner

Oh, I was not even aware that this got fixed! (You either did not bother to notify me or I missed something. Also I must have messed up my search when opening the duplicate ticket, pretty sure I did some search; sorry about that).

Anyways, thanks for the fix!

comment:6 Changed 20 months ago by simonpj

Keywords: QuantifiedConstraints added

comment:7 Changed 20 months ago by Iceland_jack

With D4353 this can be written as:

{-# Language QuantifiedConstraints #-}
{-# Language StandaloneDeriving #-}
{-# Language DeriveDataTypeable #-}
{-# Language FlexibleInstances #-}
{-# Language UndecidableInstances #-}
{-# Language KindSignatures #-}
{-# Language RankNTypes #-}
{-# Language ConstraintKinds #-}

import Data.Data (Data)
import Data.Typeable
import Data.Kind (Constraint)

data Foo f = Foo (f Bool) (f Int)

type LevelUp cls f = (forall xx. cls xx => cls (f xx) :: Constraint)

deriving instance (Typeable f, LevelUp Data f) => Data (Foo f)

Can this ticket be closed? Already closed! :-þ

Last edited 20 months ago by Iceland_jack (previous) (diff)
Note: See TracTickets for help on using tickets.