Haskell 寻找一个定理的计算解释

我有以下定理：（A）→（B）→C） )→（（A）∧（B）→C） ，我试图确定它的计算解释是什么。我有以下选择：

（1） 将当前函数转换为非当前函数的函数

（2） 将未编译函数转换为当前函数的函数

（3） 创建两个给定a值和B值的元组的函数

（4） 这个逻辑公式没有计算上的解释

我认为（1）或（2）都不正确，因为在Haskell中，所有函数都被认为是curried函数。我认为选项（3）是正确的，因为（A）∧B） 转换为类型时的元组（A，B）。然而，我不确定我的推理是否正确。有没有可能有一个curried函数，其中取前两个参数a和B，然后以某种方式将它们转换为元组，然后返回一个值C？任何见解都将不胜感激

我认为（1）或（2）都不正确，因为在Haskell中，所有函数都被认为是curried函数

这里您有点搞错了：所有像有多个参数那样编写的函数都是隐式curry函数，因此一些函数如下：

f c n = ord c + n

-- desugared:

f = \ c n -> ord c + n

f = \ c -> \ n -> ord c + n

具有一个类似于

Char->Int->Int

（具有一系列一元函数）的curried类型，而不是非carried类型

（Char，Int）->Int

（一个具有多个参数的函数，在Haskell中使用元组表示，因为它没有多参数函数的本机概念）

（1） 是正确的，因为（A）→（B）→C） )→（（A）∧（B）→C） 在Haskell类型中是

（a->（b->C））->（（a，b）->C）

，我们可以通过迭代填充孔来实现这一点

f = _ :: (a -> (b -> c)) -> ((a, b) -> c)

-- omitting redundant parentheses:

f = _ :: (a -> b -> c) -> (a, b) -> c

f

必须具有函数类型：

f = \ g -> _ :: ((a, b) -> c)

f

的结果也必须是一个接受元组的函数：

f = \ g -> \ (x, y) -> _ :: c

有没有可能有一个curried函数，其中取前两个参数a和B，然后以某种方式将它们转换为元组，然后返回一个值C

在某种程度上，但我认为这是你在这一点上混淆的地方，

f

返回的函数的结果必须是

c

类型，我们获得

c

的唯一方法是将

g:：a->b->c

应用于

x:：a

和

y:：b

。这是因为

a

、

b

和

c

都是多态类型变量：调用者指定它们，而我们在

f

中对它们一无所知

f = \ g -> \ (x, y) -> g x y

-- with some syntactic sugar:

f g = \ (x, y) -> g x y

f g (x, y) = g x y

-- example usage:

> f (+) (1, 2)
3

所以

f

正是

uncurry

，它将当前函数转换为未执行函数

(一)∧B） 是转换为类型时的元组（A，B）

这是正确的。但这并不是一个好主意→（B）→C） )→（（A）∧（B）→C） “创建两个给定a值和B值的元组的函数”。这样一个功能将是一个巨大的挑战→B→(一)∧B）

在Haskell中，所有函数都被认为是curried函数

不，那不太对。语言本身没有定义如何表达具有多个参数的函数。它没有多参数函数的概念。选择通过一次传递一个参数（curried）还是通过传递元组（uncarried）来表示多个参数函数是一个惯例问题。这些约定对库和编译器设计有着严重的影响，但从语言本身的角度来看，是否使用curry是无关紧要的

---

一种新方法的计算解释→（B）→C） 是一个接受一个参数并返回接受第二个参数的函数，即接受两个咖喱格式参数的函数。（A）的计算解释∧（B）→C是一个函数，它接受一个成对的参数，也就是说，它接受两个未配对的参数。因此，（A）的计算解释→（B）→C） )→（（A）∧（B）→C） 是一个将curried from中的函数转换为uncarried形式的函数。

在Haskell语言中，我不会说“多个参数的所有函数都隐式curried”。构造函数也是如此，在标准库中也是如此，编译器为此进行了优化，但核心语言同样可以容纳未编译的函数。就像核心ML语言可以容纳curried或uncarried函数一样，SML（编译器和库）支持uncarried，而Caml（编译器和库）支持curried。@Gilles:我的意思是多参数函数的符号，

f x y z=…

和

\x y z->…

，通过curry而不是元组或使用本机多参数函数扩展语言来定义。当然，由于它们是同构的，GHC的ABI&runtime实际上出于性能原因在内部处理多参数函数，作为经验法则，它们只在部分（非饱和）应用程序需要时分配闭包