在 FP 中处理 POST 的“正确”方法是什么？

Question

我刚刚开始使用 FP，并且正在使用 Scala，这可能不是最好的方法，因为如果事情变得困难，我总是可以退回到命令式风格。我只是不想。我有一个非常具体的问题，它指出了我对 FP 的理解中存在的更广泛的缺陷。

当 Web 应用程序处理 GET 请求时，用户需要网站上已存在的信息。应用程序只需以某种方式处理和格式化数据。 FB的方式很明确。

当 Web 应用程序处理 POST 请求时，用户希望更改网站上保存的信息。确实，这些信息通常不会保存在应用程序变量中，而是保存在数据库或平面文件中，但我仍然感觉自己没有正确理解 FP。

是否有一种模式可以处理 FP 语言中静态数据的更新？

我对此的模糊描述是应用程序收到请求和当时的站点状态。应用程序执行其操作并返回新的站点状态。如果自应用程序启动以来当前站点状态没有更改，则新状态将成为当前状态，并且回复将发送回浏览器（这是我对 Clojure 风格的模糊图像）；如果当前状态已更改（被另一个线程更改，那么，会发生其他情况......

Answer 1

在纯 FP 环境中处理此类问题的一种方法是像 Haskell 中的 monad（例如 IO 和 State），但在 Clean 中还有其他选择，例如“唯一类型”（只允许对一个值进行一次引用）。

这里没有太多需要理解的地方：如果您有可变状态，那么您需要以某种方式限制对其的访问，以便该状态的每次更改都被感知为程序其余部分的该结构的“新版本”。例如，您可以将 Haskell 的 IO 视为“世界的其他部分”，但附加了一种时钟。如果你用 IO 做一些事情，时钟就会滴答作响，你再也不会看到相同的 IO。下次你触摸它时，这是另一个 IO，另一个世界，你所做的一切都已经发生了。

在现实生活中，你可以在电影中“看到”事物如何“变化”——这是必然的观点。但如果你抓起胶片，你会看到一串不变的小图片，没有任何“变化”的痕迹——这就是 FP 视图。这两种观点在各自的背景下都是有效且“真实”的。

但是，如果您使用 Scala，您可以拥有可变状态 - 这里没有问题。 Scala 根本不需要对此进行任何特殊处理，并且使用它没有任何问题（尽管它被认为是“良好的风格”，可以使“不纯”点尽可能小）。

Answer 2

答案是单子。具体来说，状态和 io monad 将完全处理这个问题。

这是一个如何工作的示例：

trait Monad[A] {
  def flatMap[B, T[X] <: Monad[X]](f: A => T[B]): T[B]
}

class State[A](st: A) extends Monad[A] {
  def flatMap[B, T[X] <: Monad[X]](f: A => T[B]): T[B] = f(st)
  def map[B](f: A => B): State[B] = new State(f(st))
}

object IO extends Monad[String] {
  def getField = scala.util.Random.nextString(5)
  def getValue = scala.util.Random.nextString(5)
  def fieldAndValue = getField + "," + getValue
  def flatMap[B, T[X] <: Monad[X]](f: String => T[B]): T[B] = f(fieldAndValue)
}

object WebServer extends Application {
    def programLoop(state: State[Map[String, String]]): State[Map[String, String]] = programLoop(
        for {
          httpRequest <- IO
          database <- state
        } yield database.updated(httpRequest split ',' apply 0, httpRequest split ',' apply 1)
    )

    programLoop(new State(Map.empty))
}

请注意，程序中没有任何东西是可变的，但是，它会不断更改“数据库”（由不可变的 Map 表示） ）直到内存耗尽。这里的 IO 对象通过提供随机生成的键和值对来模拟假设的 HTTP PUT 请求。

因此，这是处理 HTTP PUT 并提供数据库的功能程序的一般结构。将数据库视为不可变的对象 - 每次“更新”它时，您都会获得一个新的数据库对象。

Answer 3

对于通过网络异步修改状态的 FP 最惯用的答案是延续传递风格，我猜：当前运行的函数被提供了一个延续函数作为“下一步操作”，它的调用使用当前计算产生的参数（类似于命令式返回）代表状态传递。

应用于网络，这意味着当服务器需要用户输入时，它只保存每个会话的延续。当用户响应一些信息时，保存的延续被恢复，他提供的输入经过一些计算处理，然后作为延续的值返回。

您可以在此处找到基于延续的 Web 应用程序框架示例。该想法的详细高级文章位于此处。另请参阅此处实现此功能的大量资源和 FP 应用程序。

从 2.8 开始，Scala 支持延续，并且有一个 200-300 LoC Web 服务器示例 在分布中采用连续传递风格。

Answer 4

注意：我根本不懂 Scala，所以我只是猜测示例中的语法。

这是实现映射的一种功能方法：

val empty           = x =>                scala.None
def insert(k, v, m) = x => if k == x then scala.Some(v) else m(k)
def delete(k, m)    = x => if k == x then scala.None    else m(k)
def get(k, m)       = m(k)

映射可以不是传统的数据结构，而是可以是只是一个函数。要从映射中添加或删除条目，需要将函数与现有映射组合起来以生成新映射。

我也喜欢这样思考网络应用程序。 Web 应用程序将请求转换为事务。事务将一种状态转变为另一种状态，但它可以应用于当前状态，或某些过去的状态，或某些未知的未来状态。仅仅交易是没有用的；必须有某种东西对它们进行排序，一个接一个地应用它们。但请求处理程序根本不必考虑这一点。

作为示例，请看一下 Happstack 框架模型的状态。传入请求被路由到在 monad 内运行的处理程序。部分归功于一些 TH 魔法，框架序列化了生成的 mote 并将其添加到不断增长的事务日志的尾部。要确定最新状态，只需单步浏览日志文件，按顺序应用事务即可。 （Happstack 也可以编写“检查点”，但它们并不是操作所必需的。）