F#：管道与作曲与......作曲？

我对一切都很陌生 - F#、一般编程以及这个社区。我是一名数学家，在本科期间曾短暂接触过计算机科学。我正在尝试用 F# 完成一些任务“F# 备忘单” http://dungpa.github.io/fsharp-cheatsheet/展示了三种不同的函数组合方式，但没有解释重复性。这是链接中的相关信息，看看我的意思。

The let 关键字还定义命名函数。

let negate x = x * -1 
let square x = x * x 
let print x = printfn "The number is: %d" x

let squareNegateThenPrint x = 
print (negate (square x)) 

管道操作员 |> 用于将函数和参数链接在一起。双反引号标识符可以方便地提高可读性，特别是在单元测试中：

let ``square, negate, then print`` x = 
    x |> square |> negate |> print

组合运算符 >> 用于组合函数：

let squareNegateThenPrint' = 
    square >> negate >> print

通过检查并在 VS F# 中与以下函数交互：

1. squareNegateThenPrint x
2. ``平方，求反，然后打印'' x
3. squareNegateThenPrint'

看来这是实现完全相同的 3 种方法的列表 事物， 这里有什么细微差别吗？我确信给定相同的 int 它们都会返回相同的 int，但是除此之外呢？我是什么 我没看见吗？各自的优点和缺点是什么 三种方法？

2 和 3 都使用“运算符”，而 1 似乎是组合函数以从旧函数创建新函数的常用“数学”方式。我怀疑选项 3 确实等同于选项 1（从某种意义上说>>运算符被定义为square >> negate >> print实际上计算为print (negate (square x))但代码的可读性有所提高，因为您可以按照函数名称发生的顺序查看函数名称，而不是使用通常的数学符号的相反顺序，并且通过这种方式定义可以节省一两次击键，因为您不必包含x位于函数名称的末尾，因为>>运算符可能使左侧函数自动继承对右侧函数变量的依赖，而无需显式引用该变量。

那么管道方法是如何发挥作用的呢？是否是管道 运算符 一个更通用的运算符，恰好适用于 函数组成？

另外，我在谷歌上搜索了很多，并尝试在发布之前阅读文档，但我没有得到任何结果。我确信如果我继续学习这门语言，明年的某个时候我就会理解其中的差异。但我也相信这里有人可以加快这一过程并解释或提供一些很好的例子。最后，我并不精通 C#，也不精通任何其他语言（数学除外），因此对一个完全菜鸟而不仅仅是一个 f# 菜鸟的解释表示赞赏。谢谢！

首先- 是的，所有这些方式在“逻辑上”和编译到硬件时都是等效的。这是因为|> and >>运算符定义为inline。定义大致如下：

let inline (|>) x f = f x
let inline (>>) f g = fun x -> g (f x)

的含义inline关键字是编译器将以函数体替换对函数的调用，然后编译结果。因此，以下两者：

x |> f |> g
(f >> g) x

将被编译exactly与以下方式相同：

g (f x)

然而，在实践中，也存在一些问题。

其中一个问题是类型推断及其与类/接口的相互作用。考虑以下：

let b = "abcd" |> (fun x -> x.Length)
let a = (fun x -> x.Length) "abcd"

尽管这些定义在逻辑上和编译形式上都是等效的，但第一个定义将编译，而第二个定义则不会。发生这种情况是因为 F# 中的类型推断是从左到右进行的，没有双回，因此，在第一个定义中，当编译器到达x.Length，它已经知道x is a string，因此它可以正确解析成员查找。在第二个例子中，编译器不知道什么x是，因为它还没有遇到参数"abcd" yet.

另一个问题与恐惧有关值限制 http://mlton.org/ValueRestriction。简单来说，它的定义是句法上（不符合逻辑！）value（与函数相反）不能是通用的。这有与可变性有关的模糊原因 - 请参阅链接的文章以获取解释。

将其应用于函数组合，请考虑以下代码（请注意，两者f and g是通用函数）：

let f x = [x]
let g y = [y]

let h1 = f >> g
let h2 x = x |> f |> g

Here, h2会编译得很好，但是h1不会，抱怨价值限制。

在实践中，这三种方式之间的选择通常取决于可读性和便利性。这些本质上并不比其他更好。当我编写代码时，我通常根据自己的喜好进行选择。