第 334 回 PTT のお知らせ


日時:2007年 6月21日(木) 18:30 から


場所:東京大学 秋葉原拠点 秋葉原ダイビル13階 (地図



話者:
阿部正佳(フリープログラマ)


話題:
実装言語独立でモジュラリティーの良いコンパイラキット SCK

概要:
本発表ではコンパイラキット SCK を紹介する.SCK は Emacs Lisp で実装さ れた,マルチソース,マルチターゲットのコンパイラ作成支援環境である. コンパイラキットは,単一のコンパイラと異なり,ユーザはそれ を構成する 各モジュールを選択的に利用するものであるから,それらのモジュラリィー, インタフェースの簡潔さと柔軟性が極めて重要であるにもかかわらず,既存の コンパイラ作成支援環境はその実装言語に依存した複雑なインタフェースのみ を提供し続けてきた. SCK では,データ構造というものを実装言語とは全く無関係な,独立した簡潔 なプログラミング言語として定義し,さらに徹底的なモジュール分割を行うこ とで,実装言語から独立したコンパイラ部品を提供している.実際の実装言語 は Emacs Lisp であるが,Emacs Lisp の知識がなくても SCK を利用すること が出来る.これが実装言語独立の意味である. 一方で,Emacs Lisp はコンパイラのような記号処理向きのプログラミング言 語であり,現在最も使われている完成度の高い Lisp 処理系の一つである. SCK を Emacs 上で利用するユーザには,簡潔で強力なコンパイラ作成環境が 提供される.



第 334 回 PTTメモ

出席者:31名

伊知地宏(ラムダ数教研)、並木美太郎(東京農工大)、日比野啓(朝日ネット)、
石畑清(明治大)、三廻部大(日本IBM)、和田英一、齊藤正伸、佐原具幸(IIJ)、
齋藤宏治(シンセリアル)、永松礼夫(神奈川大)、遠藤敏夫(東工大)、匿名希望、
森田直幸(ルネサステクノロジ)、繁富利恵(産総研)、山崎淳(ミラクルアーツ)、
長慎也(一橋大)、櫻田武嗣(農工大)、山口文彦、東達軌、古山大輔(東京理科大)、
竹内郁雄、筧一彦、笹田耕一(東京大)、小林弘明、五十嵐知久(元電気通信大)、
山根雅司(ワイズケイ)、多田好克、渡邊隆造、寺田実、高須賀清隆、丸山一貴(電気通信大)


質疑応答:

Q.「リターゲット」の定義は.
A.さまざまなターゲットマシンのコード生成系が「容易に」書けるという意味.

Q.「実装言語独立」の意味は.
A.各モジュールが実装言語と独立のインタフェースを持つことにより,実装言語
  以外の言語からそれらのモジュールを利用出来るという意味.

Q.SCK構成図の順は標準的なものか.
A.SCK ではモジュールを通常のコンパイラより細かく分けている.ので,標準的
  とは言えない.

Q.A-Listインタフェース(liveness)における basic-blocks とは何か.
A.分岐を含まない命令列.

Q.未定義変数を使ったときのエラーメッセージはどうなるか.
  そのメッセージはどこかに残るか.それはS式か.
A.SCK のモジュールは一般的にエラーを解析結果の S-式(in A-List インタフェース)
  としている.メッセージは現在単なる文字列になっているが,必要なら例えば
  ファイル名,行番号,カラム番号,メッセージといった情報のリストにすることは
  簡単である.

Q.このキットはどこまでできているか(完成度).SPECとかは.
A.まだ小さいプログラムでテストしている段階である.

Q.これでJavaのコンパイラが書けるか.違うファイルのクラスを探すとか….
 Java VM用の出力の定義は.
A.現在,特に Java 言語に特化したような機能は無いし,将来的にも入れない.

Q.Javaでの型の解決はどうなるか.MLは(型推論とか).
A.ML は将来的に実装したい言語の一つである.型推論部も SCK 流のモジュラーな
  構造で作りたいと思っている.

Q.中間表現にS式を使っているが,S式のparsingは面倒なのでは.
  stringのエスケープとか.XMLで書くという方法もあるか.
A.A-List インタフェースでは,Emacs Lisp から独立でプレーンな S-式に
  制限しているが,それでもその S-式の仕様を正確に定義する必要はあると思う.
  XML とのインタフェースは将来的にも入れない.

Q.「教育用」という話もあったが,その部分のサポートは(デバッグとか?).
 自分が定義した文法の間違いはどう指摘されるか.
A.現在は最終的には yacc / bison 等と同じ情報 ({shift,reduce}-recuce conflict) 
  しか出していないが,LALR(1) オートマトン作成モジュールはより詳細な情報を
  A-List インタフェースとして返しているので,それを利用してより分かりやすい
  メッセージを出すようなモジュールを作ることは容易だと思う.

Q.BNFをそのままyayaccに食わせてもうまくいくか.
A.LALR(1) でなければエラーになる.実際には,そのようなことよりも
  エラー処理が重要である.つまり言語仕様書の文法をそのまま入れてうまく
  いくとしても,実際にはエラーショリのための error アクションを追加しなければ
  ならない.yayacc も含めて現在のパーサージェネレータに欠けている最も重要な
  ものは,自動的なえらーリカバリー機構である.

Q.元のCプログラムにフックを入れるのは簡単にできるか.
 関数呼び出しの入口にプロファイル用の関数を入れる,などはどうするか.
A.SCK は全て Lisp で書かれているので,そのようなフックを入れるのは
  非常に簡単である.

Q.こういうツールの作成では,他人が書いたプログラムを食わせるとうまくいかない
  ことが多いが,それはどの程度やったか.
A.あまりしていない.

Q.今,C以外のソースを食わせることはできるか.
A.ソース言語は現在 C のみ.

Q.開発に要した期間は.
A.ほぼ半年.

Q.コンパイル速度については.
A.遅い.

Q.どのあたりが未踏なのか(from 和田 to 並木).
A.仮想コードではなく,実機のコードを生成するコンパイラを全て Emacs Lisp で
  実装するという点.

Q.実際,tmdをS式で書くのは簡単なのか.
A.他の同様のシステムと比較して,容易かつ簡潔に書ける.