也可以先用 @receiver:Wtf 这种形式，然后再看一不一样？

感觉分不清注解在哪个结构不至于吧🤔

你之前的 lexer 是基于什么……
lexer 应该不需要状态栈，我觉得用随机访问流和程序控制状态挺好的

为了兼容一个用jflex写的词法分析器.

这个冲突问题许多 JavaScript 的框架都有解决，我个人没解决过（因为我觉得程序员不该把这个问题弄出来并且交给框架解决）

方法…… 我觉得还是得先判断谁是谁的子集，拿超集的去匹配，再在结果上判断子集的匹配结果

好吧... 我觉得应该还是避免这种情况

[a-z]+ 和 [a-z]*\d+
就是
[a-z]+ (\d+)
\d+
两个嘛，你想办法从上面的集合得到下面的集合大概就好了
说白了就是分支平铺吧 🤔

a* b = b or a+ b

在咱的 ParserKt 里，这个东西的映射关系我们用一行 MapPattern 就解决了，unicode escape 我们也没用多少代码

注意这段程序里其实也是嵌入了对 \uXXXX 和 non-terminated " 的处理情况的，但我们没有任何重复代码（而且也根本不需要…… ParserKt 里是没 EOF 的，因为一般情况不需要区分 EOF 和 "剩下的字符里没有符合条件的了" 这两种情况）

ParserKt 现在对 "EOF" 的不区分的确造成了一些问题（主要是只允许利用异常来表达 EOF 与否…… 没有不会 mutate stream 的方法），下一个版本我会进行改进

HexDigits 和 FewerHexdigits 是没硬性（命名上的）区别的，如果不够会被直接当成解析失败，它们的本质都是 Repeat。

ParserKt 的另一个亮点在于采用了 Fold 架构—— asInt(16) 是纯流式读取，没有任何调用 parseInt 之内函数的需要，尽可能减少不必要的内存占用（毕竟 atoi 也就是 acc = acc*10 + v 而已……

木有啊…… 太难了，我现在的技术还是利用程序设计语言自己的调用栈和控制流状态机
如果 incremetal…… 找不到对应的替补，我之能想到一些，比如手动 slice input 再传给我们子解析器的 incremental

重要的是重复代码最好还是不要有，尤其是最后两个完全相同的 error

准备写incremental（

写完了不要忘记给我科普下怎么做那个（

🤔 https://github.com/Mivik/KiotLexer/blob/master/src/main/kotlin/com/mivik/kiot/lexer/Document.kt#L5
这里支持 index, length, seek (就是 move) 和 next, hasNext
怎么感觉有点像给 random access 扩展了个 Iterator<Char>

也是一个自动机，相同之处应该还是有（

啊我做repeat的时候要记一下

Feed 架构有点太死了感觉（这个版本就只有 peek-1 的 peek, consume() ）
下个版本我会把 ErrorHandler 重命名为更贴切的 FeedError 并且加入 FeedTerminate

我是最近一年才开始用这种「伪动态类型」的架构风格的…… 基本上就是先制定一个功能很少的基类，再利用接口和 instanceof 扩展功能

abc abc ab这种，如果来一个"abc ".repeat(2..3)的消耗，那么是需要到ab那里才能决定并回退

所以需要记一下index来回退

🤔 其实你也可以学一下 java.io.Reader ，它们那有个 mark/reset 操作，可以不必暴露完 pos (tell) / seek

虽然我之前也实现过一个（基于 List 的泛型流回溯），不过 ParserKt 现在是没有回溯功能的（而且我也不打算加入，因为我觉得 peek-1 好像也怪强大的）

其实主要还是害怕支持 backtracking 后，会使得框架实现对新手更为难懂，而 ParserKt 很重视别人理解上的开销……