《微型LISP解释器的构造与实现》中Parsec 算子的类型错误

感谢同行 Aaron，指出了书中有一些代码的算子类型错误。简单的说，Parsec 算子的基本结构有两个类型参数（部分组合子有多个，但是仍然遵循类似的设计）。作为输入和输出的类型。书中部分代码，这两个类型参数的次序颠倒。
这个历史原因在于，我最早实现这套组合子的时候，并没有想好类型结构如何定义，那时候想的是，算子的产物是最重要的，所以它的类型是决定性的，输入的类型是次要的，所以放在后面，如果将来找到方法，把输入类型变成一个隐式的存在，就可以极大的简化 Parsec 算子的定义。
另外一点就是我第一个版本是用 go 语言——那还是0.9到1.3时代的go语言——实现的，高度的倾向 go 的语法风格。其返回类型并非 either 模式，而是 result, err 风格。所以似乎这种组合思路也看不出什么问题。
一旦进入支持泛型的编程语言，就越来越感觉这种定义非常的不自然，比如 java 和 scala 有 Function[In, Out] 算子，这是最基础的函数式编程元素，它跟我过去的 Parsec 定义 Parsec[Result, Element] 这种次序是冲突的。在写了几个版本后，我最终下决心把 Parsec 的定义也修改为 Parsec[In, Out] 。这就导致了我多年来积累下来的笔记，有一部分代码跟现在的 Parsec 版本是对不上的。成书时我自己校对了几遍，但是仍然有一些漏网之鱼。
简单的说，现在的 Parsec 算子，可以看作是一个生成函数。它的定义是 Parsec[In, Out] 。当我们实现一个 Parsec，得到的产物可以看作是一个 Function[State[In], Try[Out]] 函数对象。这个函数对象的输入参数是一个有状态的 State，但是通常状态变化总是封闭在 State 中，而且它的功能也可以跟 Parsec 算子正交分解开。Parsec 算子几乎可以看作无状态的纯函数（Pure Function）——当然，较真的说，State的状态变化是Parsec调用其 next 方法而引发的，所以它通常都不是无状态的，只是状态变化局限于对 State 的修改。这个约束非常清晰，我们甚至可以定义一个算子类型，接受一个纯函数，生成对应的 Parsec 算子：

case class Func[E, T](func: Function[E, T]) extends Parsec[E, T] {override def apply(s: State[E]): Try[T] = {s.next().map(func)}
}

也可以对 Function[E, Try[T]] 做类似的封装：

case class Func[E, T](func: Function[E, Try[T]]) extends Parsec[E, T] {override def apply(s: State[E]): Try[T] = {s.next().flatMap(func)}
}

当然，要让这种封装做到足够的严谨和方便，我可能要引入一些类型映射工具。

目前我看到的是，书中第24和25页的代码中，NumberParser 类型的定义应该分别是

public class NumberParser implements Parsec {private final Parsec parser = decimal();@Overridepublic Double parse(State s) throws EOFException, ParsecException {var data = parser.parse(s);return Double.parseDouble(data);}
}

和

class NumberParser extends Parsec[Char, Double] {val parser: Decimal = decimaloverride def apply(s: State[Char]): Try[Double] = {parser ? s map {_.toDouble}}
}

后续，我会把勘误都单独发到本书的社区

https://bbs.csdn.net/forums/0df49a9c476642e68b2554d1e19ccbd5?typeId=1224564