duangsuse::Echo
717 subscribers
4.26K photos
130 videos
583 files
6.48K links
import this:
美而不丑、明而不暗、短而不凡、长而不乱,扁平不宽,读而后码,行之天下,勿托地上天国。
异常勿吞,难过勿过,叹一真理。效率是很重要,盲目最是低效。
简明是可靠的先验,不是可靠的祭品。
知其变,守其恒,为天下式;穷其变,知不穷,得地上势。知变守恒却穷变知新,我认真理,我不认真。

技术相干订阅~
另外有 throws 闲杂频道 @dsuset
转载频道 @dsusep
极小可能会有批评zf的消息 如有不适可退出
suse小站(面向运气编程): https://WOJS.org/#/
Download Telegram
Forwarded from Deleted Account
也可以先用 @receiver:Wtf 这种形式,然后再看一不一样?

感觉分不清注解在哪个结构不至于吧🤔
Forwarded from Deleted Account
你之前的 lexer 是基于什么……
lexer 应该不需要状态栈,我觉得用随机访问流和程序控制状态挺好的
Forwarded from Mivik Q
为了兼容一个用jflex写的词法分析器.
Forwarded from Deleted Account
这个冲突问题许多 JavaScript 的框架都有解决,我个人没解决过(因为我觉得程序员不该把这个问题弄出来并且交给框架解决)

方法…… 我觉得还是得先判断谁是谁的子集,拿超集的去匹配,再在结果上判断子集的匹配结果
Forwarded from Mivik Q
好吧... 我觉得应该还是避免这种情况
Forwarded from Deleted Account
[a-z]+ 和 [a-z]*\d+
就是
[a-z]+ (\d+)
\d+
两个嘛,你想办法从上面的集合得到下面的集合大概就好了
说白了就是分支平铺吧 🤔

a* b = b or a+ b
Forwarded from Mivik Q
Forwarded from dnaugsuz
在咱的 ParserKt 里,这个东西的映射关系我们用一行 MapPattern 就解决了,unicode escape 我们也没用多少代码
Forwarded from dnaugsuz
注意这段程序里其实也是嵌入了对 \uXXXXnon-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
Forwarded from dnaugsuz
重要的是重复代码最好还是不要有,尤其是最后两个完全相同的 error
Forwarded from Mivik Q
准备写incremental(
Forwarded from dnaugsuz
写完了不要忘记给我科普下怎么做那个(
Forwarded from Mivik Q
也是一个自动机,相同之处应该还是有(
Forwarded from Mivik Q
啊我做repeat的时候要记一下
Forwarded from dnaugsuz
Feed 架构有点太死了感觉(这个版本就只有 peek-1 的 peek, consume() )
下个版本我会把 ErrorHandler 重命名为更贴切的 FeedError 并且加入 FeedTerminate

我是最近一年才开始用这种「伪动态类型」的架构风格的…… 基本上就是先制定一个功能很少的基类,再利用接口和 instanceof 扩展功能
Forwarded from Mivik Q
abc abc ab这种,如果来一个"abc ".repeat(2..3)的消耗,那么是需要到ab那里才能决定并回退
Forwarded from Mivik Q
所以需要记一下index来回退
Forwarded from dnaugsuz
🤔 其实你也可以学一下 java.io.Reader ,它们那有个 mark/reset 操作,可以不必暴露完 pos (tell) / seek

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

其实主要还是害怕支持 backtracking 后,会使得框架实现对新手更为难懂,而 ParserKt 很重视别人理解上的开销……
Forwarded from dnaugsuz
https://github.com/duangsuse-valid-projects/Share/blob/master/Others/kt_misc/pkt_7/Parser.kt#L128 #parsing #Kotlin
就是在这里,我定义了
abstract class StackMarkReset<T>: MarkReset
abstract class BufferMarkReset<BUF>: MarkReset
后者被用于实现
open class Input<T>(private val feed: Feed<T>)

所以说 ParserKt 最开始是有 mark/reset 这种常见操作的
我现在也破除了对所谓 one-pass 的迷信,但因为实现起来相对复杂还是不打算恢复 >1 的预判

当然说白了不允许“预取”说到底是架构上对子解析器程序灵活性的限制,不是说不能预取就根本没法实现(但实践上它还是会对实现复杂文法增加很大难度,举个例子 (/**) ... */ 这种要判两个字符翻译过来是 Repeat(Repeat(. until '*' postfix not ('/')) ) postfix '/' 看起来十分诡异,而且非常不适合解析结果的构造 )

只不过这是 ParserKt 的选择,如果允许就有点狗拿耗子了,还是要做好自己分内的、能够并且擅长实现的工作才好。
正则擅长做的事情就让它去做,它并不落后;ANTLR 擅长的复杂文法和跨语言就让它生成解析器;ParserKt 的目标虽然不止限于 prototype 或 quick hack,但也就是个小工具,不能包容万物…… 类似 editor highlight 这种经常更新的事对 ParserKt代码就不容易复用,但整体看形式化文法的数据结构是跨任何语言和利用方式的,我很重视它们自己与生俱来的复用性。