Opened 4 years ago

Closed 4 years ago

#10541 closed feature request (wontfix)

Expose kind information for type variables with reify

Reported by: spinda Owned by:
Priority: normal Milestone:
Component: Template Haskell Version: 7.10.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

The comment on TyVarI notes that the attached Type is always VarT theName, and that this could potentially be extended. Currently, there isn't a way to access kind information for a type variable through the Template Haskell API. It would be useful (at least for me) to have this ability here.

The limitation on the returned Type comes from the ATyVar clause of reifyThing, which zonks the TyVar to a GHC type and then uses reifyType to convert it to a TH type. For a TyVarTy, reifyType always returns VarT theName.

I can see a few possible ways of exposing kind information here:

(a) Fill the Type argument to TyVarI with SigT (VarT theName) theKind. This could be done either as a special case in place of the call to reifyType in reifyThing, or as a modification to reifyType's behavior. The question of when SigT should be included is open: all the time? when the kind isn't *? when the kind is something that involves more than * and ->?

(b) Change TyVarI from TyVarI Name Type to TyVarI Name TyVarBndr. This seems like the most straightforward, stable way of exposing kind information, but it requires a breaking API change.

Change History (6)

comment:1 Changed 4 years ago by goldfire

Could you post your use-case? One thing I'm worried about here is the possibility that the result of a TH splice could affect a type variable's kind. For example:

foo :: forall a. Proxy a -> $( ... )

where the splice produces a -> a. If the code running in the splice needs the kind of a, we have a loop.

Unless I'm missing something... which is entirely possible, as something smells wrong to me in my comment.

comment:2 Changed 4 years ago by spinda

That sounds right to me. If the splice produced a b c then that would change the kind.

My use case is reading the kind in type synonyms with explicit kind signatures on certain type variables. What about possibility (b), with KindedTV where the kind is known and PlainTV where it isn't set? Or perhaps an additional Maybe Kind on TyVarI.

comment:3 Changed 4 years ago by spinda

The KindedTV/PlainTV solution matches up with ForallTy, which seems appropriate.

Last edited 4 years ago by spinda (previous) (diff)

comment:4 Changed 4 years ago by goldfire

I think we can actually do a bit better. It should be possible to tell whether we fully know a type variable's kind, by looking through the (zonked) kind for any MetaTvs. If there aren't any, then the kind is fully known and can be reported. Otherwise, don't report.

The problem with my approach here is that it's fragile, depending delicately on the order that GHC reads through a type. Perhaps your solution is better: report the kind only when it is robustly known, either through a kind annotation or other means. (For "other means", I mean, for example, when a type variable is in scope in a term, via ScopedTypeVariables. These type variables are generally fully known.)

But how do we know when the tyvar's kind is robustly known... or even just annotated? By the time reify is called, we've lost a lot of that information.

There's something we can do for you in this space, but I'm not sure exactly what yet.

comment:5 Changed 4 years ago by spinda

Hi -- just wanted to say that I don't need this anymore. Not sure if someone else does...

comment:6 Changed 4 years ago by goldfire

Resolution: wontfix
Status: newclosed

In that case, I'm going to close as wontfix. If you, or anyone else, needs this, please do reopen. I do like the idea of providing this functionality, but it's hard to motivate the time necessary if there are no eager users.

Note: See TracTickets for help on using tickets.