tokenizer 的结果往往不好看，而且即便是类似 coroutine 一样的 nextToken() Sequence 模式，tokenizer 也会造成一些 SourceLocation 对象的资源浪费
从性能的角度，tokenizer 更容易做优化吗？

https://github.com/h0tk3y/better-parse/
这个库就是纯 Kotlin Sequence<Token>

你觉得不同侧面，最好的解析器框架/解析器生成器 是什么？

我觉得……
Java 什么的当然首推 ANTLR，语法还算可以，工具也不错
JavaScript 我用过 PEG.js 和 Ohm，我觉得 Ohm 比较直观，虽然实现语义的话很麻烦
Bison/YaCC 都不行

就是说纯手写，分词器=某种状态机、解析器=递归下降？

这样的可移植性有什么好的方法吗？

🤔有道理
我只是说，如果有的话

JetBrains 的 MPS 用过没 🤔
MPS 是干什么的来着，好用吗
Kotlin 前端也是用 MPS 设计出来的？

（没兴趣就停止算了，我也就是闲聊）

听说函数式编程（类型论的那个级别）里人会提到 "lift"，据说就是“把局部变量变成参数”
把 lambda return value 给 lift 成局部函数 算不算 lift？

你觉得带返回值的 {} block 好不好？
—
听说中缀链的 动态优先级解析 在一些编译原理群里会被视为问题看待
这个问题有许多解决方案吗？ 能够用递归或者栈解决吗？ 和逆波兰表示法 有怎么样的关系呢……

如果不想学那么多，有没有好用而且简单的方法可以解决这种问题呢？

Python 还没有 lambda 表达式的时候，所用的 def fn: ...def local_fn: return local_fn 的那种方式

是一种闭包，因为可以访问 定义作用域的变量
lift 到底是什么含义？为什么会和子程序/作用域有关？

lift 是“提升”的意思啊…… 🤔

好像是

对于 X t a 被忽视的参数是 b、对 localfn 来说则是 t 啊 🤔

Problem: This is because Python's scoping rules are demented. The presence of the += assignment operator marks the target, num_converted, as local to the enclosing function's scope, and there is no sound way in Python 2.x to access just one scoping level out from there. Only the global keyword can lift variable references out of the current scope, and it takes you straight to the top.

lift 是把变量嵌套作用域扩大、提升的意思啊 🤔

局部变量变成函数参数也可以叫 lift？

如果说返回一个闭包是 lambda lifting……
这里的 "lift" 是不是在 定义顺序上 将 return lambda: 变成 def some_fun: ...def __call__: 的那种 "lift"？

https://www.minizinc.org/doc-2.4.2/en/predicates.html
Clearly, the intention of the modeller is that x=3, y=0 should be a solution. This requires the compiler to take care not to “lift” the constraint x=y*y out of the context of the function, because that would prevent it from finding any solution with x=3. You can verify that the set of solutions contains x=3, y=0 as well as the expected x=1, y=1, x=4, y=2 and x=9, y=3.

https://combinatorylogic.github.io/mbase-docs/lang0.html#lifting
Lambda lifting pass will turn all the nested lambda functions into toplevel definitions, capturing closure environments where necessary. We did the lexical scoping pass previously, and now all the names inside any given context are unique, which makes it easy to produce lists of externally defined variables used under each lambda context.

https://groups.google.com/forum/#!topic/golang-dev/JAgv8kBTgk4
Can I rely on finalizers on pointers to local variables? If so, should the documentation be updated? If not, is it reasonable to lift the restriction in general in the future? How?

https://github.com/latex3/latex3/issues/410
Presumably we have to wait for the lock to lift,