Extending call_args when specialising DFuns

[ÉRDI Gergő]

Hi,

In GHC.Core.Opt.Specialise.specCalls, when specialising a DFun call, GHC 
extends the call_args with dummy UnspecArg elements, to make it trivially 
fully saturated. There's a Note describing this behaviour:

"""
Note [Specialising DFuns]
~~~~~~~~~~~~~~~~~~~~~~~~~
DFuns have a special sort of unfolding (DFunUnfolding), and these are
hard to specialise a DFunUnfolding to give another DFunUnfolding
unless the DFun is fully applied (#18120).  So, in the case of DFunIds
we simply extend the CallKey with trailing UnspecArgs, so we'll
generate a rule that completely saturates the DFun.

There is an ASSERT that checks this, in the DFunUnfolding case of
GHC.Core.Unfold.specUnfolding.
"""

(note that the reference in the second paragraph is stale; it should point 
to GHC.Core.Unfold.Make.specUnfolding)

So my question is, why UnspecArgs instead of UnspecTypes? Unless I'm 
missing something, a DFun can't have any term parameters, only type and 
dictionary ones. Changing the padding from UnspecArg to UnspecType doesn't 
break validate, which suggests that it is hard to even exercise this code 
path.

I'm bringing this up because on the GHC fork that I'm working on, I have 
the specializer do more than vanilla GHC: on my fork, specialization of
higher-kinded type variables is just as useful as specializing 
dictionaries. With that change, I can get GHC panics when padding DFun 
calls with UnspecArgs, but not when padding with UnspecTypes. Yes, this is 
a very weak argument for this change; what I'm looking for here is a 
discussion on what the padding should be, in vanilla GHC, from first 
principles.

Thanks,
 	Gergo