Deriving Data for poly-kinded datatypes

[José Pedro Magalhães]

Hi Ryan,

I can't recall any particular reason to avoid including dataCast1 in the
Data instance for poly-kinded datatypes. Have you tried applying the
example in #4028 to a poly-kinded datatype? It might be that it was done
simply to avoid forcing the kind of the parameter to be *, and hence losing
the polymorphism (possibly at the price of losing generic function
extension).

I'm not aware of a way to define dataCast1 without the Data context. Then
again, I think it's only used for generic function extension (ext1Q and
friends); can you find a way to make that work without the Data constraint?


Cheers,
Pedro

On 23 February 2017 at 19:51, Ryan Scott <ryan.gl.scott at gmail.com> wrote:

> Hi Pedro,
>
> I'm quite confused by a peculiarity of deriving Data (more info in
> Trac #13327 [1]). In particular, if you write this:
>
>     data T phantom = T
>       deriving Data
>
> Then the derived Data instance is NOT this:
>
>     instance Typeable phantom => Data (T phantom) where
>       ...
>
> But instead, it's this:
>
>     instance Data phantom => Data (T phantom) where
>       ...
>       dataCast1 f = gcast1 f
>
> The gcast1 part is why it requires the stronger (Data phantom)
> context, as you noted in Trac #4028 [2].
>
> What confuses me, however, is that is apparently does not carry over
> to poly-kinded datatypes. For instance, if you write this:
>
>     data T (phantom :: k) = T
>       deriving Data
>
> Then you do NOT get this instance:
>
>     instance Data (phantom :: *) => Data (T phantom) where
>       ...
>       dataCast1 f = gcast1 f
>
> But instead, you get this instance!
>
>     instance (Typeable k, Typeable (phantom :: k)) => Data (T phantom)
> where
>       ...
>       -- No implementation for dataCast1
>
> This is quite surprising to me. I'm not knowledgeable enough about
> Data to know for sure if this is an oversight, expected behavior, or
> something else, so I was hoping you (or someone else highly
> knowledgeable about SYB-style generic programming) could help me out
> here.
>
> In particular:
>
> 1. Does emitting "dataCast1 f = gcast1 f" for datatypes of kind (k ->
> *) make sense? Or does it only make sense for types of kind (* -> *)?
> 2. Is there an alternate way to define dataCast1 that doesn't require
> the stronger Data context, but instead only requires the more general
> Typeable context?
>
> Ryan S.
> -----
> [1] https://ghc.haskell.org/trac/ghc/ticket/13327
> [2] https://ghc.haskell.org/trac/ghc/ticket/4028#comment:5
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20170223/83c9bbca/attachment.html>