编译器视角下两种依赖顶层入参的Haskell嵌套函数实现是否等价？

两个实现从纯函数语义上完全等价，但GHC默认优化流程不会主动将第二种实现优化为第一种的全局分支绑定形式，两种写法的实际运行开销存在明确差异。

由于Haskell是纯不可变语言，d作为test函数的顶层入参，在整个嵌套函数nestedFun的生命周期内值不会发生变化，两个实现针对任意入参返回的结果完全一致，不存在语义偏差。

• 闭包编译默认模型：let绑定的嵌套函数nestedFun默认会被编译为单一闭包对象，对应统一的函数入口。GHC不会主动将函数体内部对自由变量d的模式匹配提升到函数定义之前执行。
• 优化边界限制：GHC的公共子表达式消除、冗余分支消除等优化，仅在单次函数执行的控制流范围内生效，不会跨函数调用的生命周期为固定自由变量缓存匹配结果。除非d的值在进入let绑定时已经被上下文完全静态确定（比如test的当前执行路径本身就是前置匹配d的构造器后进入的），GHC才会直接消除对d的死分支，让两种写法的机器码完全一致。如果d是未经前置匹配的运行期变量，这种优化不会自动触发。
• 内联场景的例外：如果nestedFun的所有调用点都能被GHC主动内联到调用位置，编译器会在每个内联点发现d是固定值，进而消除对应的分支判断。但如果你的调用模式是把nestedFun作为参数传给map、filter这类高阶列表函数，nestedFun不会被逐次内联到循环内部，这部分优化不会生效。

对应Python类比对标：

• 第一种实现：d的模式匹配仅在let绑定阶段执行1次，根据d的取值直接绑定对应逻辑的lambda形成闭包。后续反复调用nestedFun时，控制流直接进入对应处理逻辑，完全不会重复执行d的构造器判断，匹配开销和调用次数无关。
• 第二种实现：所有nestedFun的调用共用同一个闭包入口，每次调用只要走到case d的分支判断（即(ft, p)匹配到有效值时），都会重复执行一次d的构造器判断。如果是对大规模列表做遍历调用，这种重复判断的开销会和有效匹配的次数线性累积，常规优化等级下不会被编译器自动消除。

直接将d的匹配提到let绑定之前，按分支绑定对应函数逻辑即可，兼顾可读性和性能：

test d ft itemNames itemHashes =
  let nestedFun = case d of
        C -> \p -> case (ft, p) of
              (Just SM.FileTypeRegular, Just p1) | Just nm <- takeFileName (cs p1) -> S.member nm itemNames
              _ -> False
        D -> \p -> case (ft, p) of
              (Just SM.FileTypeRegular, Just p1) -> S.member (hash $ cs @_ @FilePath p1) itemHashes
              _ -> False
  in -- 后续遍历大列表调用nestedFun的逻辑

这种写法下，GHC会为每个分支的lambda生成独立的静态函数，匹配d的逻辑仅在let绑定阶段执行一次，没有任何重复判断的冗余开销。

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