> ==>發信人: [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