[ruby-dev:17959] Re: next parser (Re: parenthesize argument(s) for future version)

あおきです。

  In mail "[ruby-dev:17953] Re: next parser (Re: parenthesize argument(s) for future version)"
    [e-mail] (Yukihiro Matsumoto) wrote:

> まつもと ゆきひろです

> 想定されるパーザの使い方やそれに必要とされている情報の質や量
> についてもうちょっと考えるべきですね。

では、使いたい例をいくつか挙げておきます。

  * rdoc のようなドキュメント生成系。
    構造を見つつコメントを取りたい。

  * rdtool のようなドキュメント生成系。
    =begin〜=end を取り出したい。

  * Eiffel の short のようなもの。
    完全なものは実行してみないと取れないが、静的でもある
    程度は取れると思う。特に継承を潰して flat にするのが
    やりたい。(それは flatって言うんでしたっけ？)

  * short と似ているが、クラス名とメソッド名のみ表示するもの。

  * Ruby 用の indent。
    コメントもあった場所にそのまま保存したい。

  * Ruby 用の lint。
    大部分は -w でまかなえますが個人的な好みもありますから。

  * 文字列埋め込み式も考慮して静的に変更を加える gettext。
    たとえば "a#{expr}b" を sprintf(_('a%sb'), expr) に
    変更してくれたりする。

  * irb や ruby-mode.el のような開発支援ツール。
    クラス名・メソッド名・変数名の補完は当然やりたい。

  * クラスツリー

  * コールツリー

  * クロスリファレンス

  * リファクタリングブラウザ

  * そだ、short で思いだしましたが Jcontract のように
    コメントとして表明を埋め込むのもやってみたいです。
    評価器も対応してないとダメですが、プリプロセッサ
    形式にすればありうるかなと。
    (これは defadvice 系で対処するほうがいいか……)

基本的に、構文木を返す API で心配なのはコメントや空白関係です。
どこにどんなコメントがあったのか詳しく知りたいです。

それと意味解析をするかしないかをパース開始時に指定できると
いいなあと思います。たとえばエディタなどでは BEGIN{...} が
一時的にメソッドの中にあるように見えることもありえますが、
それで色付けを全部放棄しなくてもいいと思うからです。


> |まずこれまで通り yacc ベースで作るのを前提とします。
> |ただしユーザの用意した yacc は使わず、byacc なり bison なりを
> |改造して同梱します。その改造の内容は……
>
> うーん、Rubyのコンパイルのためにわざわざbisonを改造して同梱
> するというのは、私の許容できる限度を越えそうな気がします。
> Pythonのような簡単なパーザジェネレータを持つ程度ならともかく。

許容範囲には「改造する」と「同梱する」どちらが重要でしょうか？
改造するのはぼくがやってもいいですけど、問題なのは同梱するほう
なんでしょうねえ。うーん。
-------------------------------------------------------------------
青木峰郎