duangsuse::Echo
#ParserKt 关于这个可选的 LayoutPattern，也的确是一个保留问题 🤔 不过现在可以设计一个关系式求解器了？
我已经决定了，给 ParserKt v3 的解决方案模型上做一些变通
我会引入
其中 tail 如果 parse 为 left，则视为 optional layout 的 no-layout 形式保存
否则以 optional layout 的 layout 形式保存，notParsed 语义不变
layout 还是一样。
这样就可以实现 if : 按空格后是否换行来判断 tail 了
Deep<T, L> 上保持原有的 Root, Nest, Term，Nest 的 children 为空列表则表示无 layout 的形式
Deep<T, L> 添加一个
我会引入
Either<A, B> 数据，LayoutPattern 里现在就是 item, tail, layout 了其中 tail 如果 parse 为 left，则视为 optional layout 的 no-layout 形式保存
否则以 optional layout 的 layout 形式保存，notParsed 语义不变
layout 还是一样。
这样就可以实现 if : 按空格后是否换行来判断 tail 了
ShortNest 只包含 item 和 tail 不包含 childrenParser Combinator 在语法解析的当中处于怎样的位置? - 知乎 #zhihu #parsing
https://www.zhihu.com/question/35778359/answer/64834591
后来有人发现用Memoization方法可以完美解决左递归的问题，怎么个解决方法呢？它的方法大概就是：变相Bottom Up！我之前比喻成「不断重试」引起了一些误解，然后我发现把它说成「变相的Bottom Up」似乎更易于理解，……
🤔 想想我第一次试图解决 leftrec 也是利用这种方法
“它检查到第一个分支有左递归，就直接尝试下一个分支Int并且记住这次匹配，然后再把这次匹配的结果当作Expr匹配到的东西，代进包含左递归的分支中再次重试匹配，直到失败为止”
我当初引入的是
遇到有 leftrec 的情况，LeftOr 会直接跳过、匹配余下项目并保存到 LeftOr 的状态里，然后再回来匹配 leftrec 里的情况。
不过现在 ParserKt 强制性要求不允许 left recursive 文法，而且将 operator chain 的 parsing approach 改成了
我觉得对 parserc 来说，没有“变相”这么一说，反而是那些字符串匹配算法该被视为是 parserc 的变相，因为它是最贴近程序设计语言本身的结构的解析方法
“ParserCombinator本质上就是一个递归下降算法，只不过那些状态迁移在它这里变成了函数调用而已。
Memoization本质就是查表法，通过记忆避免左递归和部分回溯。左递归可以完美解决，但只能支持局部回溯，解决之后的也许就不该叫Parsec了。参见Packrat算法还有OMeta，另外Packrat算法中有一部分跟计算First/Follow set有点类似。
ParserCombinator最大的优点是：优雅。”
这几点基本是刚接触到的人也都明白并认同的。
https://www.zhihu.com/question/35778359/answer/64834591
后来有人发现用Memoization方法可以完美解决左递归的问题，怎么个解决方法呢？它的方法大概就是：变相Bottom Up！我之前比喻成「不断重试」引起了一些误解，然后我发现把它说成「变相的Bottom Up」似乎更易于理解，……
🤔 想想我第一次试图解决 leftrec 也是利用这种方法
“它检查到第一个分支有左递归，就直接尝试下一个分支Int并且记住这次匹配，然后再把这次匹配的结果当作Expr匹配到的东西，代进包含左递归的分支中再次重试匹配，直到失败为止”
我当初引入的是
LeftOr 和 leftrec {} (那时候 ParserKt 还不叫 ParserKt，也没有 Decide 这么精确的名称)遇到有 leftrec 的情况，LeftOr 会直接跳过、匹配余下项目并保存到 LeftOr 的状态里，然后再回来匹配 leftrec 里的情况。
不过现在 ParserKt 强制性要求不允许 left recursive 文法，而且将 operator chain 的 parsing approach 改成了
InfixPattern 的递归栈模式。我觉得对 parserc 来说，没有“变相”这么一说，反而是那些字符串匹配算法该被视为是 parserc 的变相，因为它是最贴近程序设计语言本身的结构的解析方法
“ParserCombinator本质上就是一个递归下降算法，只不过那些状态迁移在它这里变成了函数调用而已。
Memoization本质就是查表法，通过记忆避免左递归和部分回溯。左递归可以完美解决，但只能支持局部回溯，解决之后的也许就不该叫Parsec了。参见Packrat算法还有OMeta，另外Packrat算法中有一部分跟计算First/Follow set有点类似。
ParserCombinator最大的优点是：优雅。”
这几点基本是刚接触到的人也都明白并认同的。
Zhihu
Parser Combinator 在语法解析的当中处于怎样的位置? - 知乎
作为一个只会写ParserCombinator不(会|爱)实现LR的也插嘴几句。Parser Combinator确实只是一种实现技巧，…
有什么代码会让你产生“这种代码我一辈子都写不出来”的想法？ - AnxQ的回答 - 知乎
https://www.zhihu.com/question/357618826/answer/913362196
才发现最后一条
https://www.zhihu.com/question/357618826/answer/913362196
才发现最后一条
#+quick-lambda看来我之前觉得红姐以往的命名方式有点语义不准确，是真的了
#+pipeline
from functools import reduce
reduce(_0 + _1, [1,2,3]) | print([_0_]*3)
Zhihu
有什么代码会让你产生“这种代码我一辈子都写不出来”的想法？ - 知乎
本人才疏学浅 但拿pipe写Python确实是我一辈子想不出来的（学长写的一个IPython扩展）https://github.com…
Forwarded from 任桑 今天开始做魔王
所以抄个别的语言的代码套在py上，我是否可以理解为你既不熟悉scheme也不熟悉py呢，不然你干嘛要抄
Forwarded from dnaugsuz
只是习惯了，好比我之前写过 Haskell，所以喜欢用
for x in xs: 一些，谁能因此断言 for 一定是 Haskell way (forM_) 或者 x/xs 一定是 Python way？Forwarded from dnaugsuz
其实我上面喷的单纯是那个必须 explicit 的 self 参数，在 Rust 这样“多范式”的语言里往往才是这样（事实上，Rust 是有 impl 的，不需要显式写 self 参数）
以及一个
给人感觉设计上不够坚定，把
以及一个
str.join 的小问题——别的语言都是 iter.join，Python 给搞个 str.join，还是“面向对象”语言给人感觉设计上不够坚定，把
re module 不和 built-in str 结合在一起可以认为是“工程”的，可 a join xs 这种命名方法完全是过分模拟自然语言语序，虽然 Python 是很早就诞生的“脚本语言”所以有些问题很正常，我觉得作者的设计水平还是感觉一般Forwarded from dnaugsuz
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
Forwarded from dnaugsuz
看来 Python 的 core devs 还是一群文艺青年，我还以为导入这个模块可以提供
this 字面名呢Forwarded from dnaugsuz
Complex is better than complicated.
是啊，可是 self 哪里比 implicit this （实际上有点像作用域策略） 更 *不* complicated 的了？
是啊，可是 self 哪里比 implicit this （实际上有点像作用域策略） 更 *不* complicated 的了？
上等讨论是交流观点，中等讨论是谈论事件，低等讨论是评判个人。
——浅谈价值表达
——浅谈价值表达
浅谈价值表达
浅谈价值表达 | 小胡子哥的个人网站
还记得刚踏入职场时，最大的困惑是不清楚未来的成长路径是怎样的，在职场上，我的未来是什么？未来的路该怎么走？业界的那些大牛，到底有多牛？我离他们有多远？对此完全没有概念。
duangsuse::Echo
上等讨论是交流观点，中等讨论是谈论事件，低等讨论是评判个人。 ——浅谈价值表达
第三次，我居然一句话没说（叮～counter+1），麻木了吗？还是我本来就不应该考虑那些事情？
我……真的不能写应用？ 🤔
我……真的不能写应用？ 🤔