Proposal: Add Data instance for Const

newer
Discussion: add pattern synonyms...

Ryan Scott

2 Nov 2016 2 Nov '16

11:40 a.m.

GHC Trac #12438 [1] exists because there's no Data instance for Const in base. I found this quite surprising, since we have Data instances for just about every other type combinator out there (Identity, Sum, Product, Compose, etc.), but not for Const. The fix for #12438 would be quite simple: I propose we add deriving instance (Data a, Data b) => Data (Const a b) to Data.Data in base. Any objections? Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/12438

Show replies by date

Eric Mertens

2 Nov 2 Nov

11:41 a.m.

...

On Nov 2, 2016, at 8:40 AM, Ryan Scott wrote:

GHC Trac #12438 [1] exists because there's no Data instance for Const in base. I found this quite surprising, since we have Data instances for just about every other type combinator out there (Identity, Sum, Product, Compose, etc.), but not for Const. The fix for #12438 would be quite simple: I propose we add

deriving instance (Data a, Data b) => Data (Const a b)

to Data.Data in base. Any objections?

Seems like an oversight worth correcting to me. -- Eric

Edward Kmett

12:05 p.m.

Definitely an oversight. On Wed, Nov 2, 2016 at 11:40 AM, Ryan Scott wrote:

...

GHC Trac #12438 [1] exists because there's no Data instance for Const in base. I found this quite surprising, since we have Data instances for just about every other type combinator out there (Identity, Sum, Product, Compose, etc.), but not for Const. The fix for #12438 would be quite simple: I propose we add

deriving instance (Data a, Data b) => Data (Const a b)

to Data.Data in base. Any objections?

Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/12438 _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Index Int

3:16 p.m.

The proposed instance is overconstrained. You only need Typeable for the second argument of Const (because it is phantom). On Wed, Nov 2, 2016 at 7:05 PM, Edward Kmett wrote:

...

Definitely an oversight.

On Wed, Nov 2, 2016 at 11:40 AM, Ryan Scott wrote:

...
GHC Trac #12438 [1] exists because there's no Data instance for Const in base. I found this quite surprising, since we have Data instances for just about every other type combinator out there (Identity, Sum, Product, Compose, etc.), but not for Const. The fix for #12438 would be quite simple: I propose we add

deriving instance (Data a, Data b) => Data (Const a b)

to Data.Data in base. Any objections?

Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/12438 _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Ryan Scott

3:27 p.m.

...

The proposed instance is overconstrained. You only need Typeable for the second argument of Const (because it is phantom).

It's a phantom type, but the Data constraint is necessary because the way deriving Data works. If You can read this [1] for an explanation behind this design decision. Essentially, if GHC sees that a datatype has two type parameters of kind *, then it generates a definition for the dataCast2 method, which allows for a higher-order version of the cast function. But implementing dataCast2 requires that both type parameters be Data instances. A separate question would be whether implementing dataCast2 could be done without these Data constraints (and thus allowing the second type parameter to only be an instance of Typeable, rather than Data). But that is outside my area of expertise; I'd need someone more knowledgeable in the arts of Data.Data than I. For now, I am proposing what GHC currently considers to be a canonical Data instance for Const. We can revisit the exact instance context details later if need be. Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/4028 On Wed, Nov 2, 2016 at 3:16 PM, Index Int wrote:

...

The proposed instance is overconstrained. You only need Typeable for the second argument of Const (because it is phantom).

On Wed, Nov 2, 2016 at 7:05 PM, Edward Kmett wrote:

...
Definitely an oversight.

On Wed, Nov 2, 2016 at 11:40 AM, Ryan Scott wrote:

...
GHC Trac #12438 [1] exists because there's no Data instance for Const in base. I found this quite surprising, since we have Data instances for just about every other type combinator out there (Identity, Sum, Product, Compose, etc.), but not for Const. The fix for #12438 would be quite simple: I propose we add

deriving instance (Data a, Data b) => Data (Const a b)

to Data.Data in base. Any objections?

Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/12438 _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Index Int

4:17 p.m.

You propose to add the line deriving instance (Data a, Data b) => Data (Const a b) to Data.Data in base. I entered it into GHCi with -ddump-deriv and this is what I got: ghci> deriving instance (Data a, Data b) => Data (Const a b) ==================== Derived instances ==================== Derived instances: instance (Data.Data.Data a_a53b, Data.Data.Data b_a53c) => Data.Data.Data (Data.Functor.Const.Const a_a53b b_a53c) where Data.Data.gfoldl k_a53f z_a53g (Data.Functor.Const.Const a1_a53h) = (z_a53g Data.Functor.Const.Const `k_a53f` a1_a53h) Data.Data.gunfold k_a53i z_a53j _ = k_a53i (z_a53j Data.Functor.Const.Const) Data.Data.toConstr (Data.Functor.Const.Const _) = Ghci4.$cBHDVlUg6FI9L4iOviG5mer Data.Data.dataTypeOf _ = Ghci4.$tBHDVlUg6FI9L4iOviG5mer Ghci4.$tBHDVlUg6FI9L4iOviG5mer :: Data.Data.DataType Ghci4.$cBHDVlUg6FI9L4iOviG5mer :: Data.Data.Constr Ghci4.$tBHDVlUg6FI9L4iOviG5mer = Data.Data.mkDataType "Const" [Ghci4.$cBHDVlUg6FI9L4iOviG5mer] Ghci4.$cBHDVlUg6FI9L4iOviG5mer = Data.Data.mkConstr Ghci4.$tBHDVlUg6FI9L4iOviG5mer "Const" ["getConst"] Data.Data.Prefix So GHC does not generate a definition for dataCast2 (and it default to `const Nothing`, I suppose). I tried the same with the constraint relaxed to Typeable and it worked. Am I missing something? On Wed, Nov 2, 2016 at 10:27 PM, Ryan Scott wrote:

...

...
The proposed instance is overconstrained. You only need Typeable for the second argument of Const (because it is phantom).

It's a phantom type, but the Data constraint is necessary because the way deriving Data works. If You can read this [1] for an explanation behind this design decision. Essentially, if GHC sees that a datatype has two type parameters of kind *, then it generates a definition for the dataCast2 method, which allows for a higher-order version of the cast function. But implementing dataCast2 requires that both type parameters be Data instances.

A separate question would be whether implementing dataCast2 could be done without these Data constraints (and thus allowing the second type parameter to only be an instance of Typeable, rather than Data). But that is outside my area of expertise; I'd need someone more knowledgeable in the arts of Data.Data than I.

For now, I am proposing what GHC currently considers to be a canonical Data instance for Const. We can revisit the exact instance context details later if need be.

Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/4028

On Wed, Nov 2, 2016 at 3:16 PM, Index Int wrote:

...
The proposed instance is overconstrained. You only need Typeable for the second argument of Const (because it is phantom).

On Wed, Nov 2, 2016 at 7:05 PM, Edward Kmett wrote:

...
Definitely an oversight.

On Wed, Nov 2, 2016 at 11:40 AM, Ryan Scott wrote:

...
GHC Trac #12438 [1] exists because there's no Data instance for Const in base. I found this quite surprising, since we have Data instances for just about every other type combinator out there (Identity, Sum, Product, Compose, etc.), but not for Const. The fix for #12438 would be quite simple: I propose we add

deriving instance (Data a, Data b) => Data (Const a b)

to Data.Data in base. Any objections?

Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/12438 _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

Ryan Scott

4:33 p.m.

Ah, right. I forgot about this additional wrinkle - GHC only checks the kinds of each type variable at the definition site, not at the site of the Data instance. And Const is poly-kinded, so its second type variable is of kind k, not *, so that's why GHC forgoes defining dataCast2 here. My bad. So in this case, I suppose it doesn't hurt to relax the second constraint to Typeable. There's the separate issue of whether this is a "correct" Data instance, but GHC won't allow us to derive dataCast2 for the Data (Const a b) instance in the first place, so it's a bit of a moot point. Ryan S. On Wed, Nov 2, 2016 at 4:17 PM, Index Int wrote:

...

You propose to add the line

deriving instance (Data a, Data b) => Data (Const a b)

to Data.Data in base. I entered it into GHCi with -ddump-deriv and this is what I got:

ghci> deriving instance (Data a, Data b) => Data (Const a b)

==================== Derived instances ==================== Derived instances: instance (Data.Data.Data a_a53b, Data.Data.Data b_a53c) => Data.Data.Data (Data.Functor.Const.Const a_a53b b_a53c) where Data.Data.gfoldl k_a53f z_a53g (Data.Functor.Const.Const a1_a53h) = (z_a53g Data.Functor.Const.Const `k_a53f` a1_a53h) Data.Data.gunfold k_a53i z_a53j _ = k_a53i (z_a53j Data.Functor.Const.Const) Data.Data.toConstr (Data.Functor.Const.Const _) = Ghci4.$cBHDVlUg6FI9L4iOviG5mer Data.Data.dataTypeOf _ = Ghci4.$tBHDVlUg6FI9L4iOviG5mer

Ghci4.$tBHDVlUg6FI9L4iOviG5mer :: Data.Data.DataType Ghci4.$cBHDVlUg6FI9L4iOviG5mer :: Data.Data.Constr Ghci4.$tBHDVlUg6FI9L4iOviG5mer = Data.Data.mkDataType "Const" [Ghci4.$cBHDVlUg6FI9L4iOviG5mer] Ghci4.$cBHDVlUg6FI9L4iOviG5mer = Data.Data.mkConstr Ghci4.$tBHDVlUg6FI9L4iOviG5mer "Const" ["getConst"] Data.Data.Prefix

So GHC does not generate a definition for dataCast2 (and it default to `const Nothing`, I suppose). I tried the same with the constraint relaxed to Typeable and it worked. Am I missing something?

...
...
The proposed instance is overconstrained. You only need Typeable for the second argument of Const (because it is phantom).

It's a phantom type, but the Data constraint is necessary because the way deriving Data works. If You can read this [1] for an explanation behind this design decision. Essentially, if GHC sees that a datatype has two type parameters of kind *, then it generates a definition for the dataCast2 method, which allows for a higher-order version of the cast function. But implementing dataCast2 requires that both type parameters be Data instances.

A separate question would be whether implementing dataCast2 could be done without these Data constraints (and thus allowing the second type

On Wed, Nov 2, 2016 at 10:27 PM, Ryan Scott wrote: parameter

...
to only be an instance of Typeable, rather than Data). But that is outside my area of expertise; I'd need someone more knowledgeable in the arts of Data.Data than I.

For now, I am proposing what GHC currently considers to be a canonical Data instance for Const. We can revisit the exact instance context details later if need be.

Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/4028

On Wed, Nov 2, 2016 at 3:16 PM, Index Int wrote:

...
The proposed instance is overconstrained. You only need Typeable for the second argument of Const (because it is phantom).

On Wed, Nov 2, 2016 at 7:05 PM, Edward Kmett wrote:

...
Definitely an oversight.

On Wed, Nov 2, 2016 at 11:40 AM, Ryan Scott wrote:

...
GHC Trac #12438 [1] exists because there's no Data instance for Const in base. I found this quite surprising, since we have Data instances for just about every other type combinator out there (Identity, Sum, Product, Compose, etc.), but not for Const. The fix for #12438 would be quite simple: I propose we add

deriving instance (Data a, Data b) => Data (Const a b)

to Data.Data in base. Any objections?

Ryan S. ----- [1] https://ghc.haskell.org/trac/ghc/ticket/12438 _______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries

3121

Age (days ago)

3121

Last active (days ago)

List overview

Download

6 comments

4 participants

participants (4)

Edward Kmett
Eric Mertens
Index Int
Ryan Scott