 |
netabareV2EX 第 125600 号会员，加入于 2015-07-05 07:57:57 +08:00 |
| 终于解决了困扰大半年（不止）的 Caps 切换中英文不顺手的问题了 macOS • netabare • 15 小时 14 分钟前 • 最后回复来自 xdidi3r | 14 |
| 计划用于生产项目里的编译器设计，适合用 LL(1)手写递归下降来实现解析器吗？
2 程序员 • netabare • 1 天前 • 最后回复来自 netabare
|
17 |
| 为什么几乎所有观察者模式的实现代码都是用副作用实现的？
1 程序员 • netabare • 19 天前 • 最后回复来自 netabare
|
23 |
| 打算设计一门集所有语言的缺点短板于一体的语言，可能从哪里开始或者有哪些功能建议呢？ 程序员 • netabare • 39 天前 • 最后回复来自 soul11201 | 85 |
| 发现自己的 commit 标题和内容越来越长了 程序员 • netabare • 190 天前 • 最后回复来自 netabare | 31 |
| Arc 浏览器用 Swift 来实现，是否意味着用 Swift 来写跨平台软件的未来也不远了？ 编程 • netabare • 253 天前 • 最后回复来自 DTCPSS | 5 |
| 这年头，参与开源项目还要付费才能参加了吗 程序员 • netabare • 284 天前 • 最后回复来自 netabare | 50 |
| 打算把 blog 从 hexo 迁移出去，不知道 nuxt content 合适吗？ Blog • netabare • 284 天前 • 最后回复来自 netabare | 19 |
| 感觉最近 Safari 好像很不稳定，不知道为什么 Safari • netabare • 304 天前 |
| 用 SwiftUI 做了个简易的找工作记录用的 App
1 分享创造 • netabare • 2023-12-23 09:05:16 AM • 最后回复来自 sherlockwoo
|
2 |
netabare 最近回复了
1 天前 回复了 netabare 创建的主题 › 程序员 › 计划用于生产项目里的编译器设计，适合用 LL(1)手写递归下降来实现解析器吗？ |
@Orlion 诶，感谢指路（似乎发现了好东西）
1 天前 回复了 drymonfidelia 创建的主题 › 游戏开发 › 现在手机游戏冷启动一个比一个慢，是否是为了延长轻度玩家游戏时间有意为之的行为？ |
我感觉还有容易断线、断线的时候会一直反复读条加载，还有玩到一半直接卡回桌面。
10 天前 回复了 netabare 创建的主题 › 程序员 › 计划用于生产项目里的编译器设计，适合用 LL(1)手写递归下降来实现解析器吗？ |
@letianqiu
@glcolof
打算做的是纯函数式编程，语法接近 ML 系或 Scala 或 Haskell （肯定没那么精简，我也在看哪些语法叠起来相对简单而不那么容易产生二义性）。长期的规划以后再看了，也许可以添加少量 OOP 功能，但肯定不是 Java 的路子。
话说过来 C++、C#和 Java 的解析难度是跟那个泛型标记有关吗？如果从我的路子讲倒是不太用担心这个问题……？毕竟按照 ML 系的类型推导，大部分时候并不需要显式标记类型，类型标记语法也可以设计成避免出现尖括号嵌套这种情况的样子。不过我不确定其他地方是否会遇到别的 LL(1)无能为力的例子了。
@Orlion
手写 LR 也可以的吗？记得都说 LR 语法好像不太适合手写反而比较适合 pg ？但我并不打算现在就考虑设计 pg 的事情。
@ftfunjth
我这边的话，快速实现可能就靠 parser combinator 了，这倒是我原先就有的路径，快速出活是真的快，但这也就回到题目里面的问题……快速写完原型后，这个原型能够长期不断扩展嘛？推倒重写应该还是基于相似的技术选型和路径，而不是说比如今天用了 flex+bison 明天改成 parsec 这样的吧。主要担心的是会不会到头来推倒重做的难度会后期逐步加大，然后语法已经复杂到重构的代价很高昂了。
@qieqie
我没有说「 parser generator 」搞不定我的语法，我想说的是我不太想用 parser generator ，因为不想被技术栈限制或者被 pg 的设计思路所限制（这是以前我遇到过的问题）。
@mahaoqu
也就是说这个问题的回答可以说是「手写递归下降足以覆盖」嘛？明白了，多谢。
@w568w
是在实现自己的语言……目前的进度大概是跳过了 parser ，实现了个解释器和类型系统。大概是计划三五年做出能真的用得上的语言（而不是简单的 toy lang ）。
@jones2000
我做的流程应该相当标准了，只是我觉得其他部分跟我想讨论的话题无关而已。解释器和类型系统我都实现了，但为了节省时间我直接跳过了 parser 步骤手写了百来个硬编码的 AST 树的测试用例，然后现在想回过头复查一下 parser 话题而已。至于中间代码和优化那些又是别的话题了。
@glcolof
打算做的是纯函数式编程，语法接近 ML 系或 Scala 或 Haskell （肯定没那么精简，我也在看哪些语法叠起来相对简单而不那么容易产生二义性）。长期的规划以后再看了，也许可以添加少量 OOP 功能，但肯定不是 Java 的路子。
话说过来 C++、C#和 Java 的解析难度是跟那个泛型标记有关吗？如果从我的路子讲倒是不太用担心这个问题……？毕竟按照 ML 系的类型推导，大部分时候并不需要显式标记类型，类型标记语法也可以设计成避免出现尖括号嵌套这种情况的样子。不过我不确定其他地方是否会遇到别的 LL(1)无能为力的例子了。
@Orlion
手写 LR 也可以的吗？记得都说 LR 语法好像不太适合手写反而比较适合 pg ？但我并不打算现在就考虑设计 pg 的事情。
@ftfunjth
我这边的话，快速实现可能就靠 parser combinator 了，这倒是我原先就有的路径，快速出活是真的快，但这也就回到题目里面的问题……快速写完原型后，这个原型能够长期不断扩展嘛？推倒重写应该还是基于相似的技术选型和路径，而不是说比如今天用了 flex+bison 明天改成 parsec 这样的吧。主要担心的是会不会到头来推倒重做的难度会后期逐步加大，然后语法已经复杂到重构的代价很高昂了。
@qieqie
我没有说「 parser generator 」搞不定我的语法，我想说的是我不太想用 parser generator ，因为不想被技术栈限制或者被 pg 的设计思路所限制（这是以前我遇到过的问题）。
@mahaoqu
也就是说这个问题的回答可以说是「手写递归下降足以覆盖」嘛？明白了，多谢。
@w568w
是在实现自己的语言……目前的进度大概是跳过了 parser ，实现了个解释器和类型系统。大概是计划三五年做出能真的用得上的语言（而不是简单的 toy lang ）。
@jones2000
我做的流程应该相当标准了，只是我觉得其他部分跟我想讨论的话题无关而已。解释器和类型系统我都实现了，但为了节省时间我直接跳过了 parser 步骤手写了百来个硬编码的 AST 树的测试用例，然后现在想回过头复查一下 parser 话题而已。至于中间代码和优化那些又是别的话题了。
11 天前 回复了 aqtata 创建的主题 › C++ › 这种情况如何消除几百个 if/else |
用表驱动和高阶函数会比较好
13 天前 回复了 exploretheworld 创建的主题 › Java › 项目全部是 map 传参 |
我之前在做 PL 作业的时候，也发现用 Java 的 Map 可以起到类似闭包作用域的作用。
13 天前 回复了 cj323 创建的主题 › 程序员 › 函数式编程适不适合游戏开发 |
游戏开发需要处理大量对象吧，似乎是计算密集型的任务，纯函数式编程会产生巨量生命周期极短的对象，似乎和游戏开发不太合得来。
不过要是写小型游戏或者后端应该会很爽，而且 FRP 和 Signal 之类的工具表现力也很强。不过能不能习惯就是另一个问题了。
不过要是写小型游戏或者后端应该会很爽，而且 FRP 和 Signal 之类的工具表现力也很强。不过能不能习惯就是另一个问题了。
17 天前 回复了 yellowbean 创建的主题 › 程序员 › 编程圈“阿诺”—— 学技术有什么用？感觉不如我 AI 速成 |
AI 补光灯是啥，没听说过
19 天前 回复了 netabare 创建的主题 › 程序员 › 为什么几乎所有观察者模式的实现代码都是用副作用实现的？ |
@zhuisui 这个也是我的想法倒是…如果非要使用副作用的话
23 天前 回复了 netabare 创建的主题 › 程序员 › 为什么几乎所有观察者模式的实现代码都是用副作用实现的？ |
@zhuisui
@mahaoqu
感谢讲解！
所以这里我想我可能陷入了一个很大的误区，就是把 visitor 机械地等同于 pattern matching ，然后把 pattern matching 在 subtyping 下面的作用（也就是 dynamic dispatch ）给搬运到了 visitor pattern 下，但是这个 dynamic dispatch 只是 visitor 的其中一个「稍微显著但不是主要的作用」，而 visitor pattern 的主要作用，就像 @mahaoqu 说的，「面向对象把一个类的多个方法放在一起，而 Visitor 模式恰好反过来了」，或者 @zhuisui 所说的「多个 visitor 分别代表可以输出不同形式的业务逻辑，visitor 之间是互相独立的」这样的作用。
我的理解是你说的「避免了业务侧用 switch case 做模式匹配，仅需 iterate elements 的 accept 方法即可完成调用」用我前面的表达其实就是「 dynamic dispatch 」对吧。比如用户解析 Tree 的时候，它不关心 Tree 具体长啥样或者具体怎么解析，它只希望能够正确的拿到 XML/JSON 或者 Table 。那么 visitor pattern 就充当了这个解析的作用吧。
这么说来倒是很多东西都说得清了。
至于副作用的问题，主要是我对这样的代码有很大的意见：
```java
class ... {
/* L.18 */ResultType result;
public void visitSomeArm(...) {
/* L.259 */ ResultType oldResult = result;
/* L.343 */ ... = visitAnotherArm(...);
/* L.569 */ result = ...;
}
public void VisitAnotherArm(...) {
/* L.1982 */ result = ...
}
}
```
当然这个其实并不是 effectful visitor 的问题而更像是某种 structural 的 code smell 了，如果一个 visitor 的实现能够把副作用清晰的表达出来，让我能够人肉去建模出 Effect 大概长啥样，我对这样的代码并没有太大的意见。
顺祝新年快乐！
@mahaoqu
感谢讲解！
所以这里我想我可能陷入了一个很大的误区，就是把 visitor 机械地等同于 pattern matching ，然后把 pattern matching 在 subtyping 下面的作用（也就是 dynamic dispatch ）给搬运到了 visitor pattern 下，但是这个 dynamic dispatch 只是 visitor 的其中一个「稍微显著但不是主要的作用」，而 visitor pattern 的主要作用，就像 @mahaoqu 说的，「面向对象把一个类的多个方法放在一起，而 Visitor 模式恰好反过来了」，或者 @zhuisui 所说的「多个 visitor 分别代表可以输出不同形式的业务逻辑，visitor 之间是互相独立的」这样的作用。
我的理解是你说的「避免了业务侧用 switch case 做模式匹配，仅需 iterate elements 的 accept 方法即可完成调用」用我前面的表达其实就是「 dynamic dispatch 」对吧。比如用户解析 Tree 的时候，它不关心 Tree 具体长啥样或者具体怎么解析，它只希望能够正确的拿到 XML/JSON 或者 Table 。那么 visitor pattern 就充当了这个解析的作用吧。
这么说来倒是很多东西都说得清了。
至于副作用的问题，主要是我对这样的代码有很大的意见：
```java
class ... {
/* L.18 */ResultType result;
public void visitSomeArm(...) {
/* L.259 */ ResultType oldResult = result;
/* L.343 */ ... = visitAnotherArm(...);
/* L.569 */ result = ...;
}
public void VisitAnotherArm(...) {
/* L.1982 */ result = ...
}
}
```
当然这个其实并不是 effectful visitor 的问题而更像是某种 structural 的 code smell 了，如果一个 visitor 的实现能够把副作用清晰的表达出来，让我能够人肉去建模出 Effect 大概长啥样，我对这样的代码并没有太大的意见。
顺祝新年快乐！
Select Language