有点头疼，undecide 和 unfold 到底是如何如何…… 那么多 extension 怎么整理……

还是先来自 high 一下吧，本苏写的这个 ParserKt，虽然只有 700 行，绝对可以说是发挥了 Kotlin 的极限……之前的一点，大部分都是不太常见的编程方法，以及 Kotlin 1.3.6 的新特性

反正平常只写那么一两个应用的开发者，肯定是写不出来的

用这个框架写的计算器，只要 30 行就能同时支持优先级、动态中缀定义、REPL 什么的，而且还包含字典树等高级操作

可以做到四两拨千斤的效果，无论是对带行号的代码文本，还是普通的序列、无论是 Char 还是 String 甚至 Int, List，ParserKt 都能完美兼容，编写有健壮性、可进行上下文相关解析的解析器，同时可以做到逆向解析、重构解析结果
用 ParserKt 的复用定义写一行等于手写递归下降解析器的五行、十行，甚至更多

🤔 看起来稍微好了点，可惜还是感觉有点复杂

不过这可是 ParserKt 啊！这么一点代码也支持了 rebuild 和镇静解析策略，提供了 error message，我也满足了。
比靠 parser compiler，生成一堆不知道是怎么工作的代码要强。Haskell GHC 的解析器都不支持镇静策略呢，输入稍微有点错误就全局爆炸。

duangsuse 你真机智，那么我们来休息一下算了，别写代码了……

我们最后玩一个梗吧，
李明开始喜欢上了坐在教室一隅的小静
现在咱有字典树了，看看怎么提取这个句子结构
李明(r) 开始(pre) 喜欢(v) 上(b) 了(b) 坐(v) 在(pre) 教室(n)一隅(n) 的 小静(r)
r=代词、引用
n=名词; v=动词
pre=前导
b=补语（迫真）

李明(r) 开始(pre) 喜欢(v) 这是一部分
(r) (v)
(v) 前面可以有 (pre)
(v) 后面可以有 (b), (pre)

(v) (pre)

坐(v) 在(pre) 教室(n)一隅(n) 的(c) 小静(r)
(n) (n) 是名词连接

艹写不下去了

enum class WordKind {
Ref, Verb, Noun, Pre, Mid, Unknown
}

typealias Word = Pair<WordKind, String>
val dict = object: TrieReplace<Word>() {
override fun from(path: String) = WordKind.Unknown to path
}.apply { }
算了不写了，狗命要紧

第975884位，但是只要我活着，就没有影响！

PPOP 😂

PPOP SURDIES CCDP SJIT

向不优雅的东西告别吧。

艹春秋大梦破灭

最底层的 SatisfyPattern 可以取 negate，我以为编译期就可以做外层包装 pattern 的 operator not 支持的

既然不支持，我不知道该怎么样了

越写越复杂，干脆不支持，手动 not 最里面那层 satisfy 好了

fun digitItem(digit: SatisfyPattern<Char>) = Convert(digit, {it-'0'}, {'0'+it})
val digit = digitItem(elementIn('0'..'9'))
Peek(!digit) {0}.clam("no octal notations") 我就想能用这个
老实说，如果 ParserKt 不支持 rebuild 那这个泛型没有问题
可是支持了，所以不能瞎弄了……

这还是我第二次破灭了，上一次是以为有了 always(T) SurroundBy 能不靠 Pair<ConstantPattern?, ConstantPattern?> 的 null test
可是实际上 ConstantPattern 的 T 值也要用来 show，所以不能用 always(value) 来随便提供一个 Unit 值，哈。
我还以为是优化的

越写泛型参数和子类型越多，越发现 Kotlin compiler 的精妙
有时候我以为是 Kotlin 类型推导错了，后来发现其实是自己的参数顺序、类型参数什么的搞错了
如果不知道类型推导有什么意义是不会领悟到这一点的，真是不容易啊
很久以前我以为类型推导就是 var pair = Pair(1, "string")，所以很容易做

如果不写这种高复用性的框架，还真是不知道类型推导可以有多方便