GHC扩展CoercibleStrings的实现可行性及相关技术问题咨询

问题解答 #

一、类型推断终止方案可行性与落地性 #

你的方案完全可以在现有GHC架构中落地，可行性很高：

• GHC的约束求解器本身就支持「仅当无其他合一规则可应用时触发fallback规则」的逻辑，和类型类默认实例的触发逻辑同源，不需要修改核心求解流程，只需要在自定义扩展的类型检查钩子中加入该优先级限制即可。
• 限定a不为String的侧条件实现非常简单，只需要在规则触发前判断目标类型的首范式是否为[Char]即可，从根源上避免规则被无限递归应用。
• 潜在冲突仅可能出现在和OverloadedStrings、RebindableSyntax这类修改字符串字面量处理逻辑的扩展共存的场景，你只需要提前定义好扩展优先级（比如CoercibleStrings优先级高于OverloadedStrings，或者共存时抛出提示）即可解决。

二、脱糖阶段插入转换的最优方案 #

不需要给所有String表达式插入调用，GHC本身提供了更轻量化的实现路径：

• 类型检查阶段完成String和目标IsString实例的合一后，可以直接给对应表达式的HsWrap字段添加对应的类方法调用标记，HsWrap本身就是GHC设计用来承载类型检查阶段生成的隐式转换、强制类型转换等逻辑的结构，不需要修改AST的核心结构。
• 脱糖阶段只需要解析HsWrap中的标记插入fromString调用即可，仅在确实需要转换的位置插入代码，不会产生冗余调用，也不会额外增加编译和优化阶段的耗时。

三、隐式转换的设计合理性与开销 #

• 这类转换不违背Haskell的设计哲学：Haskell本身就支持受控的、基于类型类的隐式转换，比如数字字面量的fromInteger、官方扩展OverloadedStrings都是同类设计，只要转换规则是确定的、无副作用的、符合用户直觉的，就属于可接受的语言扩展范畴。
• 不存在额外的不可见开销：你插入的fromString调用和用户手动编写的转换代码完全等价，运行时开销完全一致，对于常量字符串表达式，GHC的常量折叠优化还能直接将fromString调用的结果预计算为目标类型的常量，甚至比用户手动拼接String再转换的效率更高。

GHC类型检查相关参考资料 #

你可以参考GHC官方开发者文档中的《Type Checking and Inference》章节，以及GHC源码compiler/GHC/Tc/目录下的模块注释，其中TcUnify（合一逻辑实现）、TcExpr（表达式类型检查）两个模块和你的扩展实现关联度最高。

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