<div dir="ltr"><div>Short answer: This is expected behavior, and it's unlikely that behavior will change any time soon.</div><div><br></div><div>Long answer: The key phrase in your original post is "the quantifier moved". That is, in this definition:</div><div><br></div><div>> fc3 :: Int<br>> fc3 = f (const 0)</div><div><br></div><div>GHC will turn it into something like this behind the scenes when compiling it to Core:<br></div><div><br></div><div>> fc3 :: Int<br>> fc3 = f (\ (@z). const <a class="gmail_plusreply" id="plusReplyChip-0">@Int</a> <a class="gmail_plusreply" id="plusReplyChip-1">@(Maybe z)</a> 0 :: forall (z :: Type). Maybe z -> Int)</div><div><br></div><div>Note the presence of `\ (@z)`, which binds a type variable with a lambda. This process of moving quantifiers by using type variables in lambdas is called *regeneralization*.</div><div><br></div><div>A somewhat surprising fact is that GHC can only perform regeneralization some of the time. GHC can regeneralize type-level `forall`s—that is, `forall`s in the types of terms, as is the case in the example above—but it cannot regeneralize *kind*-level `forall`s. In your post, the `forall`s in the kinds of C2 and Const are kind-level `forall`s. This restriction is documented here [1] in the GHC User's Guide. I've also written a slightly longer blog post [2] about the topic.<br></div><div><br></div><div>The reason why this restriction exists is because there is no type-level counterpart to `\ (@z)` in Core, which would be required for regeneralization at the kind level. Adding type-level lambdas to Core would likely be a non-trivial effort. The UnsaturatedTypeFamilies proposal [3], which proposes to relax some restrictions about when types can appear partially applied, is the closest thing that I can think of, but it stops short of proposing full type-level lambdas.<br></div><div><br></div><div>Best,</div><div><br></div><div>Ryan</div><div>-----</div><div>[1] <a href="https://downloads.haskell.org/ghc/9.6.2/docs/users_guide/exts/poly_kinds.html#higher-rank-kinds">https://downloads.haskell.org/ghc/9.6.2/docs/users_guide/exts/poly_kinds.html#higher-rank-kinds</a></div><div>[2] <a href="https://ryanglscott.github.io/2019/07/10/the-surprising-rigidness-of-higher-rank-kinds/">https://ryanglscott.github.io/2019/07/10/the-surprising-rigidness-of-higher-rank-kinds/</a></div><div>[3] <a href="https://github.com/ghc-proposals/ghc-proposals/blob/7e380dcc4494de30f95bd15d18342eb2302430c4/proposals/0242-unsaturated-type-families.rst">https://github.com/ghc-proposals/ghc-proposals/blob/7e380dcc4494de30f95bd15d18342eb2302430c4/proposals/0242-unsaturated-type-families.rst</a></div></div>