functional-programming - 'foldp' 是否违反了 FP 的不可变状态原则？

Question

我正在从 Seven More Languages in Seven Weeks 了解 Elm .下面的例子让我困惑:

import Keyboard
main = lift asText (foldp (\dir presses -> presses + dir.x) 0 Keyboard.arrows)

foldp定义为:

Signal.foldp : (a -> b -> b) -> b -> Signal a -> Signal b

在我看来:

累加器的初始值 presses只是 0关于main的第一次评价

第一次评价后main似乎presses的初始值无论函数 (a -> b -> b) 的结果如何, 或 (\dir presses -> presses + dir.x)在示例中，是在之前的评估中。

如果确实如此，那么这是否违反了函数式编程原则，因为 main 现在维护内部状态(或者至少 foldp 是这样)？

当我使用 foldp 时这是如何工作的在我的代码中的多个地方？它是否保持多个内部状态，每次使用一个状态？

我看到的唯一其他选择是 foldp (在示例中)从 0 开始计数，也就是说，每次计算时，都会以某种方式折叠 Keyboard.arrows 提供的整个历史记录。 .在我看来，这非常浪费，并且肯定会导致长时间运行的内存不足异常。

我在这里错过了什么吗？

Answer 1

这个怎么运作

是的，foldp保持一些内部状态。保存整个历史将是一种浪费，并且没有完成。

如果您使用 foldp在你的代码中多次，做不同的事情或有不同的输入信号，然后每个实例将保持它自己的本地状态。例子:

import Keyboard

plus  = (foldp (\dir presses -> presses + dir.x) 0 Keyboard.arrows)
minus = (foldp (\dir presses -> presses - dir.x) 0 Keyboard.arrows)
showThem p m = flow down (map asText [p, m])
main  = lift2 showThem plus minus

但是，如果您两次使用来自 foldp 的结果信号，则编译程序中只会有一个 foldp 实例，结果更改将仅用于两个地方:

import Keyboard

plus  = (foldp (\dir presses -> presses + dir.x) 0 Keyboard.arrows)
showThem p m = flow down (map asText [p, m])
main  = lift2 showThem plus plus

主要问题

If this is indeed the case, then isn't this a violation of functional programming principles, since main now maintains internal state (or at least foldp does)?

函数式编程没有一些人人都使用的规范定义。有许多函数式编程语言的例子允许使用可变状态。这些编程语言中的一些向您展示了类型系统中的值是可变的(您可以看到 Haskell 的 State a 类型，但这实际上取决于您的观点)。

但什么是可变状态？什么是可变值？它是程序内部的一个值，它是可变的。也就是说，它可以改变。在不同的时间可能是不同的事情。啊，但我们知道 Elm 如何随时间变化调用值!那是一个 Signal .
真是一个 Signal在 Elm 中是一个可以随时间变化的值，因此可以将其视为变量、可变值或可变状态。只是我们非常严格地管理这个值，只允许对 Signal 进行一些精心挑选的操作。 s。这样的 Signal可以基于其他 Signal s 在你的程序中，或者来自图书馆或来自外部世界(想想像 Mouse.position 这样的输入)。谁知道外面的世界是怎么想出那个信号的!所以允许你自己的 Signal s 将基于 Signal 的过去值s其实还可以。

结论/TL;DR

你可以看到 Signal作为可变状态的安全包装。我们假设来自外部世界的信号(作为您程序的输入)是不可预测的，但因为我们有这个安全包装器，只允许提升/采样/过滤/折叠，否则您编写的程序是完全可预测的。副作用是包含和管理的，因此我认为它仍然是“函数式编程”。