Proposal: Add Data instance for Const

Ryan Scott ryan.gl.scott at gmail.com
Wed Nov 2 20:33:09 UTC 2016


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 <vlad.z.4096 at gmail.com> 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?
>
> On Wed, Nov 2, 2016 at 10:27 PM, Ryan Scott <ryan.gl.scott at gmail.com>
> 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 <vlad.z.4096 at gmail.com> 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 <ekmett at gmail.com> wrote:
> >> > Definitely an oversight.
> >> >
> >> > On Wed, Nov 2, 2016 at 11:40 AM, Ryan Scott <ryan.gl.scott at gmail.com>
> >> > 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 at haskell.org
> >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >> >
> >> >
> >> >
> >> > _______________________________________________
> >> > Libraries mailing list
> >> > Libraries at haskell.org
> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
> >> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20161102/40092e24/attachment.html>


More information about the Libraries mailing list