混乱不堪的计算器

算错了 一百除一 结果为 一百分一，一百除以一才是一百

我不喜欢除以的表示方法，就是一个名字，除号的简写。
一百除一是”一百去除一“ 1.div(100)、1 / 100
一百除以一是 100.divBy(1)
这我知道

除和除以的数学意义不一样啊

我和数学有仇，我记不住数字而且也讨厌什么”蕴含“”可知“”易证“”平凡“那一套数学专属的逻辑表达，代码在这里，你去加？

其实同时增加这两个操作符用不了两行代码，但是我就是不想加，因为 Kotlin 里面没有 divBy，我也觉得没必要区分”除“和“除以”。对“除”运算，这个主语引入的没啥意义，反正数学家现在都不用。

#Android #China #recomended #design #CG

#推荐 请点进链接查看动画介绍，OPPO 牛逼，Color OS 7 我可以（大声

https://github.com/daorys1/mulan/blob/master/ulang/codegen/ulgen.py#L387

不错，还真是研究员的风格。叫 chr 的 变量就会变成叫 char 的。

为什么有很多人执着于中文编程? - invalid s的回答 - 知乎 #zhihu #PLT
https://www.zhihu.com/question/355223335/answer/947391737

看了这篇，压死骆驼的最后一根稻草，我觉得那些不能落地的，都不算是做得实事。
中文编程曾经是笑话，我将让它不再是笑话。

我简单看了一下 ulang 的实现，ParserKt 所实现的第一门语言 可能就是它了

+ runtime/env 运行时利用库
+ runtime/main, runtime/repl 实现功能入口
顺便说一句，ParserKt 是正经的 LL(1) 流递归下降解析器，什么 match bracket 的 REPL 对我们简直是小儿科，何须用什么 is_close？

val entries = JoinBy(item(';'), stringFor(!elementIn(';', '}')) ).mergeConstantJoin()
val brk = SurroundBy(item('{') to item('}').clam {"unclosed {"}, entries)
val white = elementIn(' ', '\t') named "white"
val ws = stringFor(white).toConstant("")
val wsNL = stringFor(newlineChar or white named "ws").toConstant("")
val repl = JoinBy(newlineChar, SurroundBy(wsNL to ws, brk)).OnItem { println(it) }.mergeConstantJoin('\n')

+ parser 语法
词法处理我之前已经做了，没做完。（PKT 的 one-pass LL(1) 处理 C 风格注释是太困难了）
+ codegen 语义、代码生成（Python AST 转化）

看了这篇，压死骆驼的最后一根稻草，我觉得那些不能落地的，都不算是做得实事。
中文编程曾经是笑话，我将让它不再是笑话。

@duangsuse1 怎麼回事

绝句啊

你是指什么？我只是觉得，知乎那个中文编程组织
其实…… 努力不一定能成功、付出也不一定能得到回报
我的意思大概是，不打算和他们扯上关系。

ParserKt 并不是 LL(1) 的。实际上对于 Feed 模型，不存在 lookahead—— 一个字符的 lookahead 都不可行！！！
怎么说呢，//、/*、0x 1.0 这样的文法，支持起来非常困难，会把解析器对代码易用性的优化“打回原型”。
Contextual 这个解析模式，本来是用于给下面的解析过程加上下文的，在这样困难的时节却也可以用来适配类似的字符流模式，但由于不同的 Pattern 永远不是一家，这样的定义是困难的。

我不知道大家会怎么想 ParserKt，它现在还没实际上的文档（虽然代码里的提纲文档很丰富并且注重简洁性）

它不是算法出生，没有一点复杂的算法，说白了就是编程语言实现的时候会做的那些事，一个简单的泛型流、一个递归下降解析模式。
没有 lookahead、没有 lookbehind、没有冲突、没有匹配、没有编号、没有状态机，支持很抽象的文法模式，但它没有“编译期”，这同时是它的优点和缺点。

尽管文件里也包含一些比较复杂的算法（动态中缀链、字典树），内联文档和示例是一点也不缺的。所以不管怎么喷都不能喷它太复杂——同类框架里就它最简单了，甚至比一些 JavaScript 的框架还简单。

ParserKt 对 Feed 的严苛约束，以及对 Pattern.show 的支持看起来是搞笑，但那真的是为了简化模型，方便上手定义新 Pattern 做的，如果支持 Mark/Reset 甚至 lookahead/lookbehind，那么整个解析器的读取逻辑就不容易让人关注重点，我不喜欢那样。

但我不得不承认，对泛型流（甚至包括 nullable type）的支持，以及流的 sticky end (不能 consume 的 peek) 造成了很大的混淆
ANTLR 可以支持 EOF，但 ParserKt 没有与之等价的方法，它的 EOF 是一个 CharConstantPattern，那不完全等价。

ParserKt 对这样文法的支持写得非常难受