reify seems to needlessly remove kind ascriptions from type synonym RHSs

[nicolas.frisby]

I haven't managed to pin down where it happens in the GHC source, but it seems that using TH.reify to query a type synonym's declaration strips out kind ascriptions.

This smells a bit like LiberalTypeSynonyms .

{-# LANGUAGE TemplateHaskell, KindSignatures #-}
module Test where
import Language.Haskell.TH
type T x = ((,,) :: * -> * -> * -> *) x x
reify ''T >>= \x -> runIO (print x) >> return []

emits

TyConI (TySynD Test.T [PlainTV x_1628626975] (AppT (AppT (TupleT 2) (VarT x_1628626975)) (VarT x_1628626975)))

upon :loading in ghci 7.0.3.

My motivation for retaining those kind ascriptions is ticket:5452. I've written a TH workaround in order to avoid patching GHC. Adjusting TupleTs in the head of the unconstrained RHS of a type synonym is understandably impossible, but even if I include kind ascriptions in that type synonym, the kind inference fails. I tinkered and finally noticed that the Info returned by TH.reify ''T simply omits the SigT.

Is this an intended behavior? It seems like the TH user could easily strip out the SigTs if they so wished, and otherwise might want to see them (as I do). A show-stopper scenario for this feature request, I imagine, is that GHC sheds these ascriptions earlier in its pipeline for some terrifyingly clever reason.

[nicolas.frisby]

Independently, TySynD could have an additional field that includes its RHS's kind, or perhaps it could just always wrap its existing RHS in a SigT to preserve the interface.

[simonpj]

I'm afraid it's deliberate. 'reify' tells what is in the type environment. The kind ascription is part of the source program, but it is only used to guide the final kind GHC assigns to the type. The kind signature doesn't form part of the final type, and it would be extremely difficult to make it so -- they are two completely different data structures. (Look at HsType.lhs and TypeRep.lhs respectively.)

Anyway, #5412 is fixed!

Simon