Scala开发者学Haskell：疑惑curry、uncurry实现的类型推断与写法差异

很多人刚接触Haskell的curry/uncurry定义时，会觉得类型推导逻辑很抽象，其实整个过程完全是顺着代码字面意思做的机械推理，没有任何特殊魔法：

Curry的类型推导 #

我们逐行拆解最基础的定义：curry f a b = f (a, b)

• 首先看等号右侧的表达式f (a, b)：这里f接收的唯一参数是由a、b组成的元组(a, b)。我们先给所有未知类型打泛型标记：假设元组第一个元素a的类型是t1，第二个元素b的类型是t2，那整个元组的类型就是(t1, t2)；f接收这个元组后没有做任何额外操作，直接返回结果，那这个返回结果的类型可以标记为t，因此f本身的类型自然被约束为(t1, t2) -> t——这就是你疑惑的“因为写了f (a,b)所以f的类型是二元组参数的函数”，逻辑完全成立。
• 再看等号左侧的函数签名curry f a b：Haskell的函数应用是左结合的，也就是这串写法等价于((curry f) a) b，表示curry函数依次接收f、a、b三个参数。其中a的类型就是之前元组里的t1，b的类型就是元组里的t2，三个参数全部传完之后，最终返回的结果就是f执行后的返回值t。
• 把整个调用链的类型串起来：curry先接f（类型(t1, t2) -> t），返回一个接收a（类型t1）的函数；这个函数再接b（类型t2），最后返回t。因此完整的类型签名就是curry :: ((t1, t2) -> t) -> t1 -> t2 -> t，和书上给出的结果完全一致。
• 用fst做验证就更直观：fst本身的类型是(a, b) -> a，把它代入curry的f参数位置，对应t1 = a、t2 = b、t = a，因此curry fst的类型自然是t -> b -> t，完全不存在推导逻辑上的跳跃。

Uncurry的类型推导 #

uncurry的过程和curry是完全对称的，对应定义：uncurry f (a, b) = f a b

• 先看右侧表达式f a b：因为Haskell函数左结合，这串写法等价于(f a) b，表示f先接a，再接b，最终返回结果t。因此f本身的类型是t1 -> t2 -> t（即接收t1返回接t2的函数，再接t2返回t）。
• 再看左侧参数：uncurry第一个参数是f，第二个参数是打包好的元组(a, b)，其中a对应t1，b对应t2。
• 串起来完整类型就是uncurry :: (t1 -> t2 -> t) -> (t1, t2) -> t，和书上的定义完全匹配。

你写的带显式lambda的myCurry :: ((a,b) -> c) -> a -> b -> c、myCurry f = \a -> \b -> f(a,b)，在Haskell里完全可以正常编译运行，和原生curry的运行逻辑100%等价。它之所以不是惯用写法，根本不是代码逻辑有问题，而是它没有贴合Haskell从底层设计的核心规则，属于把Scala的显式柯里化逻辑硬套进Haskell的语法体系里：

• Scala的原生设计是不支持自动柯里化的。Scala里的函数参数是按列表分组的，一个(A, B)参数列表就是直接接收两个参数的函数，要得到柯里化版本，必须显式返回嵌套的lambda（也就是你写的a => b => f(a,b)结构），手动把两个参数拆成两层函数。
• 但Haskell从语法最底层就把“所有函数只接收一个参数，多参数效果通过偏应用实现”作为核心规则：你只要把参数名依次写在函数定义的左边，Haskell就会自动帮你搭建好偏应用的函数结构，根本不需要手动写多层\a -> \b ->的lambda。你写的显式lambda版本，本质上是把Haskell本来自动完成的语法结构，手动重复写了一遍，属于不必要的冗余。
  对比你在Scala里写的sCurry实现def sCurry[A,B,C](f: (A, B) => C) (a: A) (b: B) = f(a,b)，你会发现它已经非常接近Haskell的写法——因为用了Scala的多参数列表语法，Scala会自动推导出函数类型为(A,B) => C => A => B => C。但它和Haskell还是有两个本质区别，这也是Haskell类型系统广受认可的核心原因：
• Scala的多参数列表是可选的语法糖，不是类型系统的强制规则。你可以选择写单个参数列表，也可以选择写多个参数列表，柯里化效果是靠语法标记实现的；但Haskell的自动柯里化是类型系统的一等规则，没有例外——不管你怎么写函数定义，只要函数名后面依次写了多个参数，它的类型就一定是自动柯里化的偏应用结构，不需要额外的语法标记。
• Scala的类型推断能力没法支持全场景的泛型推导。你在实现sCurry的时候，必须手动标注[A,B,C]的泛型参数，调用fst的时候还要手动写fst[Int, Int]指定类型参数，编译器才能明确类型约束；而Haskell采用的Hindley-Milner推断规则，不需要手动标注任何泛型参数，就能从代码的应用上下文推导出所有的多态类型——就像书上的curry定义，没有任何显式类型标注，编译器就能自动推导出带三个泛型变量的多态函数，这也是大家会觉得Haskell的类型系统“更灵活”的核心原因。

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