Re: [問題] 如何學寫COMPILER? [純拋磚引玉]
> ==>發信人: tinlans.bbs@whshs.cs.nccu.edu.tw (汀), 信區: programming
> ※ 引述《sniffer@kkcity.com.tw ( )》之銘言：
> > 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
討論串 (同標題文章)
完整討論串 (本文為第 20 之 38 篇)：
Programming 近期熱門文章
PTT數位生活區 即時熱門文章
