Forwarded from duangsuse Throws
#life 建议从电脑桌上下来休息的人 采取下蹲 / 把小腿压在不太高的桌子上 的方式 舒展身体
个人感觉效果还可以，从别人分享的 PDF 上看到的。
个人感觉效果还可以，从别人分享的 PDF 上看到的。
https://www.barretlee.com/blog/2019/12/17/the-value-of-expression/ #dev #tech
作者: Barret李靖 2019-12-17 13:25:00 本文发布时间为2019年12月17日13时25分00秒 分类: 随笔 标签: 领英行家 下面是正文内容 评论数: 0 热度: 280
领英中国近期推出了一个年度行家的榜单，关注我的朋友可能知道，我有幸入了榜。
领英对行家的定义是，在自己的领域中，根据自身经验和知识，为他人答疑解惑，分享行业洞察，提供经验干货。简单来说，所谓的行家，就是善于思考，乐于发声的人。
作者: Barret李靖 2019-12-17 13:25:00 本文发布时间为2019年12月17日13时25分00秒 分类: 随笔 标签: 领英行家 下面是正文内容 评论数: 0 热度: 280
领英中国近期推出了一个年度行家的榜单，关注我的朋友可能知道，我有幸入了榜。
领英对行家的定义是，在自己的领域中，根据自身经验和知识，为他人答疑解惑，分享行业洞察，提供经验干货。简单来说，所谓的行家，就是善于思考，乐于发声的人。
浅谈价值表达
浅谈价值表达 | 小胡子哥的个人网站
还记得刚踏入职场时，最大的困惑是不清楚未来的成长路径是怎样的，在职场上，我的未来是什么？未来的路该怎么走？业界的那些大牛，到底有多牛？我离他们有多远？对此完全没有概念。
duangsuse::Echo
下去散步的时候想了一下 ParserKt 的 LayoutPattern 处理可选的 layout 的问题，感觉有点复杂 所谓可选的 layout，就是： if p: op() #无 if p: #有 op1() op2() 和带不带花括号的区分方式处理上差别不太大，都是判 1 字符。 ParserKt 里限制非常大，因为是严格的 peek(1)，没法预判 不过对于 if，可以定义这种 Pattern<Char, AST> 。 LayoutPattern 是基于 item / tail…
#ParserKt 关于这个可选的 LayoutPattern，也的确是一个保留问题 🤔
不过现在可以设计一个关系式求解器了？
不过现在可以设计一个关系式求解器了？
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 是很早就诞生的“脚本语言”所以有些问题很正常，我觉得作者的设计水平还是感觉一般