为何启用LiberalTypeSynonyms扩展仍触发类型同义词参数不匹配编译报错？

这类报错的本质是对扩展生效边界的理解偏差，具体逻辑可以拆解为以下几点：

• 对扩展设计逻辑的常见误解
  不少人读文档时会把“先展开类型同义词再做有效性校验”的描述，理解成扩展会跳过所有类型同义词的前置校验，把所有同义词全展开完了再走流程，但实际上这个“先展开”的规则，仅作用于kind校验环节内部，不会改动类型检查器的固定流程顺序。
• 类型检查器的固定执行顺序
  GHC处理类型表达式的流程是硬编码的，不受该扩展的影响：
  1. 解析阶段：碰到类型同义词标识符时，立刻查询它定义时绑定的形参总数，统计当前使用位置给它传递的实参数量。如果实参数量少于定义的形参数，直接抛出参数数量不匹配的错误，这个环节完全不参考上下文对类型kind的要求。
  2. 只有通过解析阶段的参数数量检查，才会进入kind推导、匹配的环节。此时碰到类型同义词，才会按照扩展的规则先展开，再做kind校验。
  3. 所有kind校验通过后，才会在生成具体类型表示的环节，把类型同义词替换成最终的展开结果。
• 两个示例的实际流程差异
  • MyEither1是零形参定义的类型同义词，在Optionally MyEither1 Int的使用场景中，传递的实参数量是0，刚好匹配它定义的形参数，顺利通过解析阶段检查。后续kind校验时，推导得到它的kind为* -> *，完全匹配Optionally第一个参数的kind要求，因此可以正常通过编译。
  • MyEither2是带1个形参定义的类型同义词，在Optionally MyEither2 Int的使用场景中，传递的实参数量是0，比定义的形参数少1个，直接在解析阶段就触发了参数数量不足的报错，根本走不到后续kind校验、同义词展开的环节，哪怕它的实际kind完全符合上下文要求也无法通过校验。
• 扩展的实际能力边界
  LiberalTypeSynonyms 的设计初衷，是解决已经通过解析阶段检查的部分应用同义词的kind匹配问题：比如给一个带N个形参的同义词传了N-1个实参，通过了解析阶段检查，展开后剩余1个形参，kind刚好匹配上下文要求的场景，扩展会允许这种部分应用的合法使用。但它从未改动过解析阶段的硬规则——当你完全不给带形参的同义词传递任何实参、直接把它作为类型构造器使用时，一定会被解析阶段的校验拦截。

内容的提问来源于stack exchange，提问作者MorJ