Last updated:
Apr 04 09:27:02 2001
[MJ Top page]
[Site map]
シンタックスシュガー程度の言語拡張ならば、 デバッグがそれほどしにくくなることはありません。
複雑な機能拡張をする場合は、実装の仕方によっては 確かにデバッグがしにくくなります。 言語仕様と実装の設計をする際には、デバッグのことを常に考慮する必要があります。
これは拡張部品の設計者のセンスの問題に帰着されます。 言語の拡張は最後の手段であって、できるだけ普通のライブラリとして 提供できないか、検討すべきだと思います。
拡張部品はライブラリと同じで、それが入手可能である限り、 ソースコードの可搬性は保証されます。 つまり、十分安定した「言語拡張インターフェース」のもとで 拡張部品を作っている限りは、可搬性は問題にはなりません。
拡張部品の「実装規約」により、衝突を回避することが可能だと考えています。 PC 部品における plug-and-play のような規約です。 plug-and-play に対応した部品ならば、リソースが自動的に割り当てられるため、 エンドユーザは容易に組み合わせて使うことができます。 同様の機構を入れることで、衝突の問題に対処したいと思います。
JavaDoc や prity printer などの関連ツールも、 言語処理系自身と同一のフレームワークを用いて実装すれば、 拡張された言語機能もほぼ自動的に処理可能になると思います。
１つめの答えですが、拡張部品記述言語と拡張APIをうまく設計することで、 部品の組み合わせが少しでも容易になるようにするつもりです。
２つめの答えとしては、 すべてのプログラマーが、自分で部品を組み合わせることにはならないと思います。 例えば、現在のパソコンも、自分で部品を組み合わせるのは一部のユーザだけで、 ほとんどのユーザは、大手メーカーやパソコンショップが 動作確認した組合せを利用しているにすぎません。 linux の distribution もそれに似ています。 ほとんどのユーザは、有名な distribution をほとんどそのまま使います。 カーネルのコンフィギュレーションの調整や、 ライブラリのバージョンを変えることは、必要最低限しかやりません。
核となる言語仕様はバランスのとれた小さいもので、 それに対して、用途に応じてちょっとした拡張を加えることができる、 という言語が理想だと思います。
lisp, forth, tcl はいずれも核となる言語仕様をシンプルにし、 文法にも強い制約を入れることで、拡張性を高くすることに成功しています。 しかし、文法に強い制約があることと、静的型チェックがないため、 一般のプログラマーによるアプリケーション開発には向かず、 ソフトウエア開発の主流の言語にはなっていません。
comp.compilers の moderator の John 氏によると、拡張可能言語は 1970 年代に流行ったそうです。 このころは拡張の対象は文法で、 on-the-fly で文法拡張できる Earley's algorithm を使った EL1 という言語が有名だったようです。 現在の我々ならば当然予想するように、 各プログラマーが勝手に文法を拡張できるので、 読みにくいプログラムになったようです。 文法を定義するのはプログラマーではなく、 センスのよい一部の言語設計者に限れば、 可読性の問題は生じないと思います。
|
|
Last updated:
Apr 04 09:27:02 2001
[MJ Top page]
[Site map]
|