ParserKt 我觉得它可以考虑下，是不是要允许有一个 StatedFeed…… 我注意到 检查闭括号的程序的错误提示，好像需要开括号的位置……

🌚 #PLT https://github.com/OrangeX4/Orangex/blob/master/map/dict.json#L78 这…… 各位大佬怎么看？

https://github.com/OrangeX4/Orangex/blob/master/nodejs/src/%E6%B5%8B%E8%AF%95/%E5%AD%90%E7%9B%AE%E5%BD%95/%E6%B5%8B%E8%AF%95.txt.%E6%A9%99#L49
eval 为什么被翻译成了硬编码…… ”求值“和”执行“都可以啊？

#life #China #PL #dev #GitHub #zhihu

我开始还以为这个前端蛮大佬的，后来发现他也是纯工程之人……

整个项目到现在维护了十几天才弄完，最近一次修改是 3days ago
项目的核心算法是 file tree walker 和 regex punctuation(标点) split / replace 以及 Map (k-v) pair ops，和基础的 read/write/parse。

最重要的是，尽管这个目的 不很复杂 且代码的复用性（我没太严格）还算可以，但项目居然有 107 commits 1,417,608 ++ 1,409,848 --，这就有点匪夷所思了…… 莫不是一开始把 node_modules 提交了上去

我昨天晚上还花了点时间用 ParserKt 的 TriePattern 复制了核心业务功能——文本替换，用的不是标点分词而是 Trie 树，效果与之差不多

其实我一直很犹豫 应不应该靠近『中文编程组织』的这些人，因为他们大部分人都（说真话）太菜了，而且 我没特别看到什么大佬。

更没见过真正有实用价值的”中文编程语言“，文言(wenyan)和东北语(dongbei) 都不在实际上有工程能力，它们写出的代码不仅不能算 general-puropse，更缺乏可读性、可维护性。

他们和 @iseki_w 也不一样，iseki 虽然总体上好像比较菜，偶尔也是能研究的。

感觉这些人呢，虽然一直有在努力，可几乎从未进步过，甚至好像是因此才希望有中文编程来帮助他们”重整旗鼓“，不得不考虑。

https://github.com/duangsuse-valid-projects/Share/blob/master/Others/kt_misc/pkt_9/Parser.kt#L1293

@iseki_w 我用来处理缩进布局的算法概念上没有问题了，但还没测试 🤔

不过我注意到现在的情况好像有点缺陷，它不能解析

class Dog(name: String) where
  val somePropDef = 1
  fun speak(): String where
    return "$name speaking"

这种情况，因为 LayoutPattern<IN, T, L> 还没支持根据 item, tail 动态决定 children 采用的 pattern…… 🤔

找到了两个 bug，但原因在确定

>>> p.read("12334\n1234\n122->\n  1->\n   22\n2\n3\n0\n")
res29: Deep<kotlin.Int, kotlin.String>? = Root(nodes=[Term(item=12334), Term(item=1234), Nest(item=122, tail=->, children=[Nest(item=1, tail=->, children=[Term(item=22)]), Term(item=2)]), Term(item=3), Term(item=0)])

>>> p.read("12334\n1234\n122->\n  1\n 2\n  3\n0\n")
res18: Deep<kotlin.Int, kotlin.String>? = Root(nodes=[Term(item=12334), Term(item=1234), Nest(item=122, tail=->, children=[Term(item=1)])])

呀…能处理那种缩进风格的文法了？🤔

两个 bug 都解决了。我把一个整数大小比较写错了。

@iseki_w 是的，支持 layout 的解析和（调试性）复显了（毕竟正经的语言肯定会重写这类代码，我没保留 layout 本身的解析结果）。

有很大把握可以在明天完成对 contextual LayoutPattern 的支持以及对 ParserKt 最后的检查，这样绝句的实现从 Layout 到 Infix 动态解析到汉字数值终于扫清了所有障碍，终于可以松口气了。

val item = RepeatUn(asInt(), digitFor('0'..'9')) { i -> i.toString().map { it - '0' } }
val tail = Seq(::CharTuple, item('-'),item('>')).toStringPat()
val layout = Convert(Repeat(asString(), item(' ')).Many() prefix item('\n'), { it.length }, { "".padStart(it) })
val p = LayoutPattern(item, tail, layout)

就是这四行代码定义的布局解析器，现在我重构后已经支持 依据 item 和 tail 确定新布局里的解析项目了，但还没测试。

/** [Pattern.show] for resulting pattern should be general, since [show] does not use this function */
protected open fun decideLayerItem(parsed: T, parsedTail: L): Pattern<IN, T> = item

在我看来，ParserKt 的 LayoutPattern 和 传统方法 最大的差别就是
- PKT 的是 scannerless parsing，lexer-parser 的话那不是最后一层操作（各有优缺）
- Lexer 用数据栈、PKT 用系统栈（个人 profile，用系统栈貌似块那么几ms）
- PKT 没有利用 state，而把 state 建立在递归用栈里（当然它其实也是完全支持 contextual parsing 的）
- PKT 依赖 Deep { Root, Nest, Term } 这种递归数据结构存储解析结果，要再次转化为 AST 必须使用 Deep.Visitor（缺点）
- PKT 的 LayoutPattern 支持 rebuild，对调试很方便
- PKT 的 decideLayerItem; item, tail, layout 都是抽象的，而且 onNestIndent、onTermIndent 也都可重写。代码复用性很高（优点）

@CodeHz 大佬，冰封之前也写过 lexer 层面把布局解析为内部 END token 的做法，你觉得我们这两个实现有啥优缺点呢 ~ 请dalao分析……