https://twitter.com/iorioikawa/status/1237287329351356416?s=19

#计算机 #Linux

#China #freedom

“发哨人”引发的中国网络奇观
閱讀原文 | 作者：守望者

忍不住想到 《 寂静之城 》

中文（中国大陆）新话化不可避（叹气

希望下一代能够自由毫无挂虑地使用汉语。

#微博新鲜事 禁止套娃

#linux #sysadmin 更新了

#dev 老家的人觉得用电脑对眼睛不好，这几天 ParserKt 不开发了

#film 《 我想吃掉你的胰脏 》

校园爱情动漫片 soulmate

#China #Low

#微博存档 流行性感恩

#film 生活留学 《 陪伴安东尼度过漫长岁月 》 一男主二女主

其实我对 ParserKt 的 LexerFeed 怎么改还蛮疑惑的

主要就是 SourceLocation 要可选地加入，但是好像没有好方法，如果直接在 Feed 上解析的话

而且还要有类似 regex 的 group range 支持，有 GreedyLexerFeed，我不知道是不是应该为需要 Source loc 和不需要的情况分开处理

不过突然觉得 greedy 与否可以复用处理……

TokenizerFeed 支持 Source loc
LexerFeed 不支持？

有了！ 我可以利用 TokenizerFeed.onError 啊
这样不就可以把 token stream 的 position 弄回包含原来 CharInput 的 position 的版本了……

就这样了！都是流式处理
tokenizer 带 range，lexer 不带

可是我觉得非 SourceLocated 也应该有 position 啊……

example.SimpleArithmetic 🤔 可以跑分来着呢

duangsuse 2020-03-12 18:31:39
@定理证明器 不过说起来，ANTLR 4 是无法处理 Layout 和 non-CFG 的，ParserKt 可以用 LayoutPattern 直接支持，如果觉得有什么建议可以看看 https://github.com/ParserKt/examples/blob/master/extendedSyntax/src/commonMain/kotlin/LayoutInts.kt

此外，NumUnitPattern 可以在三行内定义 1min30s 这种数值单位格式的读取和显示，不过我写过有趣点的操作是读取汉字数值
（并且顺带写了个同时支持汉字和阿拉伯数字的计算器REPL）
https://github.com/ParserKt/examples/tree/master/hanCalc/src/commonMain/kotlin

ParserKt 本质上感觉是序列模式匹配（解析状态化文法的能力是与生俱来的），而不止是字符流（虽然 ANTLR 也有吹自己能处理二进制格式，不过我觉得对所有解析器实现这都是高射炮打蚊子，emmm）

超高校级的门卫 2020-03-12 19:03:46
parser = 序列模式匹配

超高校级的门卫 2020-03-12 19:05:28
你们怎么都这么喜欢scannerless

超高校级的门卫 2020-03-12 19:06:46
似乎和我当年一样，是一个parserc

超高校级的门卫 2020-03-12 19:06:59
parsec enhanced

超高校级的门卫 2020-03-12 19:07:06
好的，我认可了。

超高校级的门卫 2020-03-12 19:07:38
这个表达力很强，但是性能呢

超高校级的门卫 2020-03-12 19:09:11
我的意见啊，non-CFG，有个回溯，非常简单。以及你有做左递归处理吗？有做分支合并之类的优化嘛？

超高校级的门卫 2020-03-12 19:15:36
antlr已是历史，是成型的，已知会被淘汰的"现在的临时的技术"。你和它比就算你是它的闭包也没有意义，人们只会用antlr是因为技术潮流迭代是比较缓慢的。
你要比的话，业界你至少也得和各方面最好的比。nonCFG你可以去研究它的性能优化

duangsuse 2020-03-12 19:31:22
@超高校级的门卫 感谢大佬指点(｀･ω･´)ﾉ

duangsuse 2020-03-12 19:36:07
差不多是这样，ParserKt 和少部分 parser combinator 一样会提供从输入到解析结果的数据表示管理（而不仅仅是到 List 什么的），比如 Repeat 会被 Fold asString() asList() 甚至 asInt() asLong() asMap() 什么的parse = extract data from sequence = transform inputs into simpler form

超高校级的门卫 2020-03-12 19:37:33
parse会把flatten的序列变成结构化序列

超高校级的门卫 2020-03-12 19:37:54
asInt这种叫做action/rewrite

duangsuse 2020-03-12 19:39:34
Feed 是一个非常简单的模型，只有 peek 和 comsume()我实现了 SliceFeed 和 StreamFeed，前者用于 CbarSequence, List 什么的，后者用于 InputStream 等整个解析过程都不需要 if hasNext，我用的是 Python 式异常如果要吐槽，我觉得该喷 incremental parsing 和 multi thread、bulk processing（而不是一次一字符） 啥的

duangsuse 2020-03-12 19:40:46
是的，我把 Iterable.fold 提升了一个层次，变成 interface Fold
所以它就可以在折叠过程中保存一个状态了

超高校级的门卫 2020-03-12 19:40:46
我没喷

duangsuse 2020-03-12 19:41:01
（我是说，如果要的话

今泉影狼 2020-03-12 19:41:30

我就负责表情包制作



超高校级的门卫 2020-03-12 19:41:48
你说的话里太多的东西都是和你的project相关的

超高校级的门卫 2020-03-12 19:42:25
你能不能找到相关知识具体的专业术语对应呢？

超高校级的门卫 2020-03-12 19:43:03
如果你这样下去，退一万步即使你很厉害无人能及，走的再深也没人会care

超高校级的门卫 2020-03-12 19:43:52
在折叠的过程中保持状态并非是你做的第一次尝试

超高校级的门卫 2020-03-12 19:44:45
存在大量的parsing工具可以maintain 一个global的context，乃至针对每个production的local context

duangsuse 2020-03-12 19:44:46
没有(>﹏<)，毕竟我觉得，既然都是 parserc 了，编程者自己要负责代码质量我举个最简单的例子， (anyChar and !item(wtf)) 实际上就是 !item(wtf)但即便去掉 and，实际上 SatisfyPattern.not 里也是多包了一层光从 instance 创建性能上谈，是不利的但是这个框架的代码质量也很重要啊…… 不可能为了一切可能的优化都 多写逻辑吧( •̥́ ˍ •̀ )

超高校级的门卫 2020-03-12 19:46:19
我早期写的所有parser框架几乎都有state maintain。但现在我内心实话觉得这些就是菜逼，没用，我自己都不会用。我只会用最快的，写的快，跑的快，debug快

duangsuse 2020-03-12 19:46:26
这个东西其实一半是自用，现在还打算继续重构另外我本该学那些，但后来我发现…… 大佬们太厉害了索性就做些小白都能看懂的东西，跟随 Kotlin 的步伐，别用太多术语和高深抽象的概念。

超高校级的门卫 2020-03-12 19:48:28
很多的优化人写出来都会很难看的。况且没有左递归的话，其实你的表达力非常的有限

duangsuse 2020-03-12 19:49:43
半个月的编写过程里我甚至没用 IDEA（旧电脑性能渣）
还是比较看重代码可读性的，每个部分都有注释提纲。

内联文档当然还是少些好，如果名字和定义的顺序本身就可以表示些什么…… 我干脆一点文档都没写

超高校级的门卫 2020-03-12 19:50:16
你这话别人读起来是有点反智的。你这个项目的progress是不差的，但是我想说你这里做的东西，只是parsec框架实现上很简单的事情。不考虑左递归，很多人可以在数小时乃至数十分钟内写出相差无几的框架。

duangsuse 2020-03-12 19:50:58
@超高校级的门卫 所以我有更“高性能”的 InfixPattern而且我考虑过左递归，在 Feed/Pattern 模型里是完全没问题的，虽然现在我懒得实现了……

超高校级的门卫 2020-03-12 19:51:22
你确定完全没问题？要不要试一下

duangsuse 2020-03-12 19:51:48
我想，问题不在于你花多短时间，在于别人可以节省多少时间和输出代码体积……

duangsuse 2020-03-12 19:52:09


超高校级的门卫 2020-03-12 19:52:21
是的，那我说，别人写的框架用起来还可以比你简洁

超高校级的门卫 2020-03-12 19:52:48
你看过fastparse嘛？

超高校级的门卫 2020-03-12 19:53:07
你知道bnf嘛? parser gen知道吗？

duangsuse 2020-03-12 19:53:08
聪明是好事，可是我是个愚钝的人呢……
所以我只能把有限的智慧，放在优化别人的理解和使用上

超高校级的门卫 2020-03-12 19:53:32
就我看来，你的框架用起来代码特别多

duangsuse 2020-03-12 19:53:47
的确的，但除了简洁，易读也是相当重要的呢

超高校级的门卫 2020-03-12 19:54:29
我以前也和人说过你这样的观点，最终应该是消除冗余的信息，利用(e)dsl

超高校级的门卫 2020-03-12 19:54:49
现在问题来了，简洁，性能，可读性

duangsuse 2020-03-12 19:54:56
定义有结构层次，不滥用语言特性

就像 SurroundBy(clamly(parens), wtf)
会比 wtf surroundBy parens.clamly() 好看一样

超高校级的门卫 2020-03-12 19:55:13
三者，你的评估规则是什么？

超高校级的门卫 2020-03-12 19:55:57
这个例子我认同，过分使用语言特性是不利的

duangsuse 2020-03-12 19:56:15
都很重要如果一定要舍鱼取熊掌，我选可读性，因为程序灵魂的表达才是核心。

超高校级的门卫 2020-03-12 19:56:54
但edsl对相当一部分人，远没有dsl的可读性

超高校级的门卫 2020-03-12 19:57:00
别人会使用bnf

duangsuse 2020-03-12 1

9:57:35
简洁就是把自然语言变成数学，首先它就不是 Kotlin 的选择

性能是要看 profile 的，而且我相信足够的抽象反而可以在未来带来更好的性能

超高校级的门卫 2020-03-12 19:57:48
别人甚至会讨厌你提供surrounded by这样的组合子

duangsuse 2020-03-12 19:58:23
ParserKt 也有一门 "bnf" DSL 已经设计，还没时间实现

超高校级的门卫 2020-03-12 19:58:42
你如果能把性能优化作为重点，那也是可以的。parsec唯一的优点是类型安全，而其上的优化有大量文章可做

超高校级的门卫 2020-03-12 20:01:38
parsec没有优化的话，中型的parser，比如json这些比LR/LL codegen慢个几千倍不是很难

超高校级的门卫 2020-03-12 20:02:14
常见编程语言的parsing就要更慢了

超高校级的门卫 2020-03-12 20:03:20
https://github.com/lihaoyi/fastparse/blob/master/README.md

超高校级的门卫 2020-03-12 20:03:36
你可以先比一下

超高校级的门卫 2020-03-12 20:03:44
找出你有哪些优点

超高校级的门卫 2020-03-12 20:03:58
他作为一个标杆，是比较菜的

收藏于昨天  群-迂腐的学院派编译技术

#qq #PLT