“无积分”的优点和缺点是什么？函数式编程的风格？

Question

我知道在某些语言（Haskell？）中，努力是实现无点风格，或者从不按名称显式引用函数参数。这对我来说是一个非常难以掌握的概念，但它可能会帮助我理解这种风格的优点（甚至可能是缺点）。谁能解释一下吗？

Answer 1

无点风格被一些作者认为是终极函数式编程风格。简单来说，t1 -> 类型的函数t2 描述从 t1 类型的一个元素到 t2 类型的另一个元素的转换。这个想法是，“有意义的”函数（使用变量编写）强调元素（当您编写 \x -> ... x ... 时，您正在描述元素x发生了什么），而“无点”函数（不使用变量表达）则强调变换本身，作为更简单变换的组合。无点风格的拥护者认为，转换确实应该是中心概念，而有点符号虽然易于使用，但却分散了我们对这一崇高理想的注意力。

无点函数式编程已经存在很长时间了。自 1924 年 Moses Schönfinkel 的开创性工作以来，研究组合逻辑的逻辑学家已经知道了这一点，并且是 Robert Feys 和 Haskell Curry 在 20 世纪 50 年代首次研究 ML 类型推理的基础。

从一组富有表现力的基本组合器构建函数的想法非常有吸引力，并且已应用于各个领域，例如源自 APL，或解析器组合器库，例如 Haskell 的 秒差距。无点编程的著名倡导者是 John Backus。在 1978 年的演讲《编程能否从冯·诺依曼风格中解放出来？》中，他写道：

lambda 表达式（及其替换规则）能够
定义所有可能类型的所有可能的可计算函数
以及任意数量的参数。这种自由和权力有它的
缺点以及明显的优点。这是类似的
传统中不受限制的控制语句的力量
语言：不受限制的自由会带来混乱。如果有一个
不断发明新的组合形式以适应场合，
一个人可以在 lambda 演算中，一个人不会熟悉
几种组合形式的风格或有用的属性
足以满足所有目的。就像结构化编程一样
避开许多控制语句以获得更简单的程序
结构、更好的性能和统一的方法
理解他们的行为，所以函数式编程会避开
lambda 表达式、替换和多重函数
类型。从而实现了用熟悉的方式构建的程序
具有已知有用特性的功能形式。这些程序是
如此结构化，他们的行为通常可以被理解和
通过机械使用类似于那些的代数技术来证明
用于解决高中代数问题。

所以他们在这里。无点编程的主要优点是它们强制采用结构化组合器风格，使等式推理变得自然。 “Squiggol”运动的支持者特别宣传了等式推理（参见 [1] [2]），并且确实使用了相当一部分的无点组合器和计算/重写/推理规则。

• [1] “Bird-Merteens 形式主义简介”, Jeremy Gibbons, 1994
• [2] “用 Bananas 进行函数式编程、透镜、信封和铁丝网”，Erik Meijer、Maarten Fokkinga 和 Ross Paterson，1991

最后，无点编程在哈斯克尔派中流行的原因之一是它与 类别理论。在范畴论中，态射（可以看作“对象之间的变换”）是研究和计算的基本对象。虽然部分结果允许以有点风格执行特定类别的推理，但构建、检查和操作箭头的常见方法仍然是无点风格，并且其他语法（例如字符串图）也表现出这种“无点性”。提倡“编程代数”方法的人和编程中类别的用户之间存在相当紧密的联系（例如香蕉论文 [2] 的作者是铁杆类别主义者）。

您可能对 Haskell wiki 的 Pointfree 页面感兴趣。

pointfree 风格的缺点相当明显：阅读起来确实很痛苦。尽管存在许多令人恐惧的阴影、alpha 等价等问题，但我们仍然喜欢使用变量的原因是，它是一种非常容易阅读和思考的表示法。总体思想是，复杂函数（使用引用透明语言）就像一个复杂的管道系统：输入是参数，它们进入一些管道，应用于内部函数，重复（\x -> (x,x)) 或忘记了（\x -> ()，管道无处通向）等。并且变量表示法很好地隐含了所有这些机制：你给出一个输入的名称，输出的名称（或辅助计算），但您不必描述所有的管道计划，其中小管道不会成为较大管道的障碍，等等。在像 \(f,x,y) ->; 这样短的东西中进行管道连接((x,y), fxy) 太棒了。您可以单独跟踪每个变量，或者读取每个中间管道节点，但您永远不必一起查看整个机器。当您使用无点样式时，所有管道都是明确的，您必须写下所有内容，然后再查看，有时它简直是丑陋的。

PS：这种管道愿景与堆栈编程语言密切相关，堆栈编程语言可能是（几乎）使用中最没有意义的编程语言。我建议尝试在其中进行一些编程，只是为了感受它（就像我建议逻辑编程一样）。请参阅因子、猫或可敬的Forth。

Answer 2

我相信目的是简洁并将流水线计算表达为函数的组合，而不是考虑线程参数。简单的例子（在 F# 中） - 给出：

let sum = List.sum
let sqr = List.map (fun x -> x * x)

使用如下：

> sum [3;4;5]
12
> sqr [3;4;5]
[9;16;25]

我们可以将“平方和”函数表示为：

let sumsqr x = sum (sqr x)

并使用如下：

> sumsqr [3;4;5]
50

或者我们可以通过管道 x 来定义它： 以

let sumsqr x = x |> sqr |> sum

这种方式编写，很明显 x 正在被传入仅通过一系列函数“线程化”。直接合成看起来更好：

let sumsqr = sqr >> sum

这更简洁，并且是思考我们正在做的事情的不同方式；组合函数而不是想象参数流动的过程。我们没有描述 sumsqr 的工作原理。我们正在描述它是什么。

PS：了解组合的一个有趣方法是尝试使用连接语言进行编程，例如 Forth、Joy、Factor 等。这些可以被认为只是组合（Forth : sumsqr sqr sum ;< /code>），其中单词之间的空格是组合运算符。

PPS：也许其他人可以评论性能差异。在我看来，组合可以通过使编译器更清楚地知道不需要像管道一样生成中间值来减少 GC 压力；帮助使所谓的“森林砍伐”问题更容易处理。

Answer 3

虽然我被无点概念所吸引并将其用于某些事情，并且同意之前所说的所有积极因素，但我发现这些事情是消极的（一些在上面详细说明）：

1. 较短的符号减少了冗余;在高度结构化的组合中（ramda.js 风格，或者 Haskell 中的无点，或者任何连接语言），代码读取比线性扫描一堆 const 绑定并使用符号荧光笔更复杂查看哪个绑定进入其他哪些下游计算。除了树结构与线性结构之外，描述性符号名称的丢失使得该函数难以直观地掌握。当然，树结构和命名绑定的丢失也有很多优点，例如，函数会感觉更通用 - 不通过所选符号名称绑定到某些应用程序域 - 并且树结构在语义上甚至存在如果绑定已布局，并且可以按顺序理解（lisp let/let* 样式）。

2. 当只是通过管道传输或组合一系列函数时，无点是最简单的，因为这也会产生我们人类易于遵循的线性结构。然而，通过多个接收者进行一些临时计算是很乏味的。有各种包装成元组、透镜和其他艰苦的机制，只是为了使某些计算可访问，否则这只是某些值绑定的多次使用。当然，重复的部分可以作为一个单独的函数提取出来，也许这是一个好主意，但是某些非短函数也有参数，即使提取出来，它的参数也必须以某种方式通过两个应用程序进行线程化，然后可能需要记住该函数，以免实际重复计算。人们会使用很多converge、lens、memoize、useWidth等。

3. JavaScript 特定：更难随意调试。通过 let 绑定的线性流程，可以轻松地在任意位置添加断点。使用无点样式，即使以某种方式添加断点，值流也很难阅读，例如。您不能只查询或将鼠标悬停在开发控制台中的某些变量上。另外，由于 point-free 不是 JS 原生的，ramda.js 或类似的库函数会使堆栈变得相当模糊，特别是在强制柯里化的情况下。

4. 代码脆弱，尤其是在规模较大的系统和生产中。如果出现新的需求，那么上述缺点就会发挥作用（例如，下一个维护者在几周后可能就是你自己，很难阅读代码，也很难跟踪数据流进行检查）。但最重要的是，即使是看似小而无辜的新需求也可能需要完全不同的代码结构。也许有人会说，这是一件好事，因为它将是新事物的清晰表示，但重写大量无点代码非常耗时，而且我们还没有提到测试。因此，人们认为，更松散、结构性较差、基于词汇分配的编码可以更快地重新调整用途。特别是如果编码是探索性的，并且在具有奇怪约定（时间等）的人类数据领域中，很少能够 100% 准确地捕获，并且可能总是存在即将到来的要求更准确地处理某些内容或更符合用户需求的请求。对于客户来说，无论哪种方法能够带来更快的转变都非常重要。

Answer 4

对于无点变体，即串联编程语言，我必须写：
我对乔伊有一点经验。喜悦是一个非常简单而美丽的列表概念。将问题转换为 Joy 函数时，您必须将大脑分成两部分，一部分负责堆栈管道工作，另一部分负责 Joy 语法中的解决方案。堆栈总是从后面处理。由于合成包含在 Joy 中，因此合成组合器没有计算时间。