> ==>发信人: [email protected] (汀), 信区: programming > ※ 引述《[email protected] ( )》之铭言： > > parser 只是负责把 C++ code 转成内部 structure, > > 会出问题通常是内部表示 data structure 没规划好 ... > > 可以用 BNF 都算好 parse ... > parser 这东西没有你所想像的简单， > 因为软体开发常常是渐进式的， > 而标准制订过程本身也是渐进式的， > parser 的开发不可能一开始就规划好全套， > 通常都是先做一个 subset， > 然後随着时间演进慢慢加慢慢修， > tool 太弱的话遇上「变」就会出事。 > 在 C++ syntax 被证明成可用 LL(1) 实作之前， > 很多人都在猜 C++ parser 没有 LR(2) 搞不出来， > 因为许多人使用 bison 这个 LALR(1) parser generator 实作都碰壁得很惨， > 不单是 LALR 和 LR 支援 syntax 的能力之差所造成的错觉， > 还常常会遇上 lookahead 的 token 不够的问题。 > 一个 grammer 能用 BNF 表示， > 并不会代表它的 parser 好写， > 因为 BNF 可以随你高兴写， > 但写出来的 form 不见得适合 context-free LALR(1) parser 去 parse。 就学习来讲, 先学如何把一个语言用 context free 的 BNF form 表达出来是 该先学的. 其次是工具与 BNF 表示法的关系, 定位工具是做那一阶段的事. > > 无法预期会挂在那才会去 trace, 当然要任何点都能 trace > > 不然 assembly level trace 做给谁用 > 做给 compiler 设计者用， > 还有一些想 tune 自己 application 效能的人用。 > 这种 trace 的方向根本就是偏了， > 无法预期挂在哪里的问题， > 就算用这种方法也一样找不出来， Bug 如果能预测也就不成为 bug 了. 如果这种 bug 不是 time dependent error , 都是能用穷举或二分逼近的. Compiler 的算法里应该是没有这种不确定性的成份. 当然, 如果在剖析整 个原始程式的过程如果先对不明确的部份(通常是 data type 或初值)先做 假定, 到後面再回溯重定义(这就会是前後文相关), 就会有类似前後次序性 质的 time dependent 问题. Time Dependent Error 通常不是 trace 就能对付除错的. > > C++ 做过头, 规定太多, 才会有 java, c# 跑出来 > 你搞反了， > 是 C++ 太自由， > 所以规定太多的 Java 和 C# 才会跑出来， > 给 programmer 许多比「公约」更严的语言性限制。 自由也可以说成是彼此认知不同, 各自随意表述, 最後就是随 compiler 的 implementation 而不同. 学 compiler 当然是得将语法与语义确认清 楚, 但会冒出那种用法会译出那种实际动作, 也不是完成那个 compiler 的人能完全掌控的, 这跟 "思考不周" 造成的 bug 是类似的. > > 真正优良的程式靠的是规划, 用那一种 library, tool, language 都没用 > > 第一个 pascal compiler 用 pascal 写, > > 第一个 java compiler 用 java 写, 用某个程式语言来写出该语言的 compiler 是基於一个完整的语言该有 self-description 的能力, 不会只是某个有力语言的子集. 其次是这样 做会让 copiler 程式精简, 在实做时只要做出基础的模组就能整个实现 出来. > > compiler 跟语言本身一起完成, 靠的就是切割得好 > 我想你可能没有抓到问题的重点， > 原 po 问的是用 lex/yacc 好不好， > 表示这时他已经选择了「工具」， > 突然讲「程式规划」会让人感觉是来乱的， > 并不是说「程式规划」不重要， > 而是说「程式规划」在目前的这个主题而言不重要， > 我要说的是 lex/yacc 这个工具很老旧， > 我们有更好的工具可以用， > 有更好的工具自然也能让 programmer 更专注於程式规划和设计上， > 这两者并不冲突， > 不管开发任何程式都需要使用工具， > 不单只是 library 和 code generator， > language 本身也是一种工具， > 在规划程式之前如果不正确的选择好工具， > 那也只是纸上谈兵罢了， 利用别的语言工具产生自己的工具, 再用自己的工具再重造自己的工具, 就是借腹生子的概念, 感觉会比较便捷. 但进入要有自己语言产生的工具 时, 就会碰上原先是否够周密的麻烦, 万一漏了制定某种叙述, 少了某种 能力时就得再借腹生子重来. 同时也会让人觉得这是依附在某种语言的子 语言的感觉. > 尤其是 code generator， > 因为如果它生出来的是 legacy code， > 你还要准备好各种 workaround 来应付它， > 而这个准备动作也是程式规划的一环。 code generator 还会碰上 linking loader 与 run-time environment 规范的限制 . -- ◎ Origin: 中央松涛站□bbs.csie.ncu.edu.tw From: 140.115.6.234