看起来 ParserKt 的确是能够用来辅助设计语法，但要想优雅地用于实际目的，很难……

这时候 one-pass 和 rebuild 反而成为了两个傲娇的特性，就比较难受……

Seq 不能用，得用 SurroundBy
Seq(::AnyTuple, *(item<Char>()-'*')) 还有这种用法表达一个 Until pattern……
也是无奈啊
如果允许添加扩展方法，这其实不是多困难的，可在没 IDE 的情况下我不方便做这些非核心的工作……

不是很难……我相信，只是还有点距离…… 初心和理论是好的，就是实现上后来有点小偏差……

现在的 ParserKt 虽然对辅助语法设计有很好的作用，也没见很严重的 bug，但写出来的代码依然不是很易读……

有点头疼，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 好了