From: "machida,tatsuhiko" <t.machida.unicom jcom.home.ne.jp>
Subject: [langsmith:178] Re: 自作言語とパーサー 
Date: Tue, 12 Apr 2005 11:54:56 +0900

> > まず最初にパーズ後の中間表現を外部に出力したり、それを手で編集して
> > 読み込めるようにする部分を作ります。
> 
> 　この外部出力するものって、中間コードってことですよね。
> 　ということは、自前ＶＭ用の簡易アセンブラ／ディスアセンブラ環境を作っている
> 　ってことでしょうか......大変そうですね。

ここで言っていたのは、基本的にはパーズ後の構文木ということで、
VMのアセンブラよりはずっと上流の表現です。

ここで処理を分けられるようにしておくことにはいくつもメリットがあります。

- 開発の初期段階で、パーザのテストがバックエンド無しで出来る。
  (出力される構文木を目視で確認すればよい)

- 構文木を読み込んで直接解釈する試験用のバックエンドを作るのは、
  最適化VMを作るよりもはるかに楽なので、「とりあえず動く」状態まで
  素早く持ってゆくことが出来る。試験用のバックエンドは最終的な実装言語で
  書く必要さえない (例えば最終的にVMをCで書くとしても、エミュレータを
  手に馴染んだ高級言語で書くことができる)

- 構文糖衣の実験など、ユーザに見える部分の変更が、バックエンドとは
  独立して行える。

- 構文木の段階でtree変換をかけるツールを別に作れば、VMの機能をいちいち
  追加せずに高度なフロントエンドの機能を試すことができる
  (VMがCで書かれているとしても、tree変換の部分を一時的に別言語で
  書いて試してみることができる。関数型言語はtree変換が得意)

- 構文仕様が固まっていないうちにも、構文木を入力とすることでバックエンドの
  開発とテストを進められる。これは共同開発をしている時なんかにとても便利。

- 処理系が出来上がった暁には、ターゲット言語のプログラムを読み込んで
  メタな処理をするプログラムが簡単に書ける。

構文木よりもVMに近いところの中間表現も取り出せると役に立つ場合がありますが、
VM寄りになるとデータサイズがふくれあがったり、共有構造や循環構造を
持つようになって手でいじりにくくなったり、外部に簡単にダンプできない
情報を持ったりすることが多いです。それでも出力だけは出来るように
作って置くとデバッグ時に大きな助けになりますが。
簡易ディスアセンブラのような道具類も、一度作ってしまうと開発が圧倒的に
楽になりますよ。

> > 一方、自分で文法から決められる場合は、解くべき問題の全体像をより深く理解
> > してから文法を悩んだ方が良いので、先にバックエンドから手をつけると思います。
> 
> 　(1) 中間コード形式の定義(ファイル定義?)
>   (2) 中間コードのアセンブラ/ディスアセンブラ環境の開発
>   (3) ＶＭの開発
>       ※(1)〜(2)で、ＶＭが実行すべき中間コードファイルが生成される
>   (4) ジェネレーターでパーサ作成

私の感覚としては、「中間コード形式の定義」と「データ構造のデザイン」は
ほとんど同義です。データ構造を作ったらそれが中間コード形式の定義に
なっています。

Lisp系言語を実装言語として使っている場合、S式を使えば入出力は自動的に
ついてくるので、中間コードファイルを読んでどうの、ということは特に考えません 
(Cで書かざるを得ない時でもS式の入出力ルーチンを書いて使うことはあります)。

上で述べたように中間コード形式は構文木なので、(2)はアセンブラというより
VMコードへのコンパイラそのものになりますね。ディスアセンブラは道具として
別に作ります。

> 　文法を自分で決定できる場合に、パーサーからＶＭまでの開発で、
> 　力点はどこにあるでしょうか？
> 　例えば、
> 　　　中間コード形式決定:ＶＭ開発:パーサー開発 = X : Y : Z
> 　なんていうマインドシェア(負荷?)みたいなのがきけると嬉しいです。

ケースバイケースです。

--shiro

--
ML: langsmith quickml.atdot.net
使い方: http://www.atdot.net/~ko1/quickml