よくあるプログラム言語の作成の本って
字句解析→構文解析→中間言語
ってウォーターフォールっぽく進むじゃないですか
僕もそういう本。結構、読んだんですけど
順番が逆じゃないのかな？と思うんですよね
中間言語とかいってそれはなくてもいいと思うんですけど
まああってもいいんですがｗ
内部表現と記述しましょうか
内部表現の仕様をしっかり把握してないと
構文解析のアウトプットの仕方を構成出来ないし
構文解析の仕組みを把握してないと字句解析出来ないんじゃないかな？
と思うんです
なんでそう思うかというと
簡単めの書籍で
入力を一行単位で入力してるんです
まあ最初の方なんですけど
字句解析も構文解析もすっとばして
いきなり内部表現にアクセスしてる訳ですな
そして割と最初の方でスタックのダンプ関数用意してます
スタックマシンなんで内部表現がスタックの構成割合が多いんですね
スタックをダンプする事が重要なのではなく
内部表現の見える化が重要なんでしょうね
内部表現は割と解決されている。と思うかもしれませんが
僕がちょこちょこ写経/書写してるホワイトスペースという簡単言語は
結構、色々な言語バージョン（CとかRubyとかPythonとか）
で書かれてるバージョンがあるんですけど
それぞれによって内部表現違うんですよね
言語それぞれに解法は一つとも違って
RubyでPython風にも書けるでしょうし、RubyでC風にも書けるっぽいです
逆にCでRuby風とかは辛いっぽそうでしょうけど
字句解析に正規表現使ってたりしますから
まあ、結構、作者の考え方によって
内部表現の表現に仕方って分かれるんじゃないのかな？って思います
書籍も色々あって
こうウォーターフォールじゃなく
アジャイルに発展を繰り返しながら発展していく書籍も結構あるんですけど
それでも考え方は一緒で
字句解析の発展→構文解析の発展→内部処理の発展
と進みます
なんていうか
そっちの方が説明し易いからそう書いているだけで
作者は割と同時進行で考えている気がします
でもそれも
内部処理の変更を把握しないと構文解析の変更を把握出来ないでしょうし
構文解析の変更を把握しないと字句解析の変更を把握出来ないと思うんです
同時進行でやる人も多いかもしれませんが
自分は、yaccとかも駆使してコーディングしたい気もありますが
やっぱいきなりyacc駆使は無理なんかなーみたいな
手で小型構文解析を繰り返して慣れてきてからっぽいっすね
後、言語処理系作りたくてもやっぱりプログラミングスキルも必要なのかな？と
才能じゃなく（それも重要なんですがｗ）作業量も必要っぽいっす
いわゆる一万時間の学習的な
自分は一万時間目指して写経/書写頑張って4年くらい経ち
15万行くらいっすｗ 一時間に100行（150行くらいやれる気もしますがｗ）
だとすると1500時間っすね。プログラミングそのものとか
書籍読んだ時間とももあるから純粋にそうじゃないけど
才能が無い事を嘆く前に学習量を積めって自分に言ってるごとしでした