Forwarded from 天天向上 (Basic I/O Interface)
The latest version of CMake (3.17.1) was released.
Forwarded from Mivik Q
最近用新的思路写个基于状态的lexer，但是想到一个问题
假设有字符串abc123，然后你有两个token类型，一个匹配[a-z]+，一个匹配[a-z]*[0-9]+，那么lexer应该决定使用哪个token🤔
假设有字符串abc123，然后你有两个token类型，一个匹配[a-z]+，一个匹配[a-z]*[0-9]+，那么lexer应该决定使用哪个token🤔
Forwarded from dnaugsuz
啊， 这个看到了；明天再看看
感觉不在我的领域之内，我只是写解析组合子的，那个主要是代码复用封装设计而非列表/关系处理算法和代码生成。
感觉不在我的领域之内，我只是写解析组合子的，那个主要是代码复用封装设计而非列表/关系处理算法和代码生成。
Forwarded from Haruue | 春上ひつき
好像没有直接的方法。。
Show Kotlin Bytecode 然后变回 Java 看？
Show Kotlin Bytecode 然后变回 Java 看？
Forwarded from Deleted Account
也可以先用
感觉分不清注解在哪个结构不至于吧🤔
@receiver:Wtf 这种形式，然后再看一不一样？感觉分不清注解在哪个结构不至于吧🤔
Forwarded from Deleted Account
你之前的 lexer 是基于什么……
lexer 应该不需要状态栈，我觉得用随机访问流和程序控制状态挺好的
lexer 应该不需要状态栈，我觉得用随机访问流和程序控制状态挺好的
Forwarded from Deleted Account
这个冲突问题许多 JavaScript 的框架都有解决，我个人没解决过（因为我觉得程序员不该把这个问题弄出来并且交给框架解决）
方法…… 我觉得还是得先判断谁是谁的子集，拿超集的去匹配，再在结果上判断子集的匹配结果
方法…… 我觉得还是得先判断谁是谁的子集，拿超集的去匹配，再在结果上判断子集的匹配结果
Forwarded from Deleted Account
[a-z]+ 和 [a-z]*\d+
就是
[a-z]+ (\d+)
\d+
两个嘛，你想办法从上面的集合得到下面的集合大概就好了
说白了就是分支平铺吧 🤔
a* b = b or a+ b
就是
[a-z]+ (\d+)
\d+
两个嘛，你想办法从上面的集合得到下面的集合大概就好了
说白了就是分支平铺吧 🤔
a* b = b or a+ b
Forwarded from dnaugsuz
注意这段程序里其实也是嵌入了对
ParserKt 现在对 "EOF" 的不区分的确造成了一些问题（主要是只允许利用异常来表达 EOF 与否…… 没有不会 mutate stream 的方法），下一个版本我会进行改进
HexDigits 和 FewerHexdigits 是没硬性（命名上的）区别的，如果不够会被直接当成解析失败，它们的本质都是
ParserKt 的另一个亮点在于采用了 Fold 架构——
\uXXXX 和 non-terminated " 的处理情况的，但我们没有任何重复代码（而且也根本不需要…… ParserKt 里是没 EOF 的，因为一般情况不需要区分 EOF 和 "剩下的字符里没有符合条件的了" 这两种情况）ParserKt 现在对 "EOF" 的不区分的确造成了一些问题（主要是只允许利用异常来表达 EOF 与否…… 没有不会 mutate stream 的方法），下一个版本我会进行改进
HexDigits 和 FewerHexdigits 是没硬性（命名上的）区别的，如果不够会被直接当成解析失败，它们的本质都是
Repeat。ParserKt 的另一个亮点在于采用了 Fold 架构——
asInt(16) 是纯流式读取，没有任何调用 parseInt 之内函数的需要，尽可能减少不必要的内存占用（毕竟 atoi 也就是 acc = acc*10 + v 而已……Forwarded from dnaugsuz
木有啊…… 太难了，我现在的技术还是利用程序设计语言自己的调用栈和控制流状态机
如果 incremetal…… 找不到对应的替补，我之能想到一些，比如手动 slice input 再传给我们子解析器的 incremental
如果 incremetal…… 找不到对应的替补，我之能想到一些，比如手动 slice input 再传给我们子解析器的 incremental