高校数学の窓過去問検索

GNU 機能拡張用言語計画(GNU Extension Language Plans) Richard Stallman, GNU Project [再配布大歓迎]

多くのソフトウェアパッケージは、ユーザが機能の追加や変更を容易にできるような機能拡張用言語（Extension Language）を必要としている。本稿では、機能拡張用言語についての GNU の計画を説明する。

Tcl が機能拡張用言語として不適切であるという結論を最初に文書として発表したときに、私は GNU システム用の機能拡張用言語の設計目標について少しのべたが、特定の選択肢を選ぶことはしなかった。

その時点では、私はどうすべきかの結論には至っていなかった。どのような場所へ行きたいかは分かっていたが、正確に何処へ、またそこへどのように行くべきかが分かっていなかった。

それ以来、私はこの話題について多くを学んできた。scsh、 Rush や Python について書かれたものを読んだり、Scheme を機能拡張用言語/スクリプト言語として使うべく作業している人々と話したりした。今、私はGNUシステムに拡張性を提供するための具体案を展開できるようになった。

Why Tcl is a bad choice
Tclでは何が不足なのか



拡張可能なアプリケーションプログラムやツールへの興味が高まり、Tcl を使う誘惑にかられるプログラマもいるが、私たちは、最初に広く使われた拡張可能なテキストエディタである Emacs で学んだ教訓を忘れてはならない。

Emacs の一番の教訓は、機能拡張用の言語は単なる「機能拡張用言語」であってはならない、ということである。しっかりしたプログラムの作成と保守ができるように設計された本当のプログラミング言語でなければならない。なぜなら、人々がそうしたいからである!

しばしば、拡張機能はそれ自体が大規模で複雑なプログラムになり、拡張機能の作成者は、他のプログラマ達があてにするその機能に値することになる。

最初の Emacs は、TECO という文字列処理言語を使っていたが、これは適切ではなかった。私たちは TECO を役立てたが、TECO は私たちのやり方に口をはさみ続けた。これによって保守が難しくなり、拡張機能を書くのも難しくなった。処理系作成者がこの問題から学んだことで、その後の Emacs 処理系は、より強力な言語を使うようになった。

Emacs のもう一つの教訓は、拡張機能を本当に柔軟なものとする方法は、その拡張機能を使って正規にリリースされるシステムの大部分を書く、ということである。Tcl を使ってこれを行なおうとすれば、ユーザは Tcl の制限事項に行き当たる。

Tcl は、きちんとした（seriousな）プログラミング言語たるべく設計されたものではない。「スクリプト言語」（scripting language）は真のプログラミング言語である必要はないという仮定の下で言えば、それは「スクリプト言語」として設計されたものである。だから Tcl は、真のプログラミング言語としての能力を持っていない。Tcl には配列データ型や構造体データ型がない。数値データ型は疑似的に実現しており、これは動くけれども遅くならざるを得ない。Tcl は小さなプログラムを書くぶんには OK だが、大きなプログラムを書こうとすると適格ではなくなる。

Tcl は、その単純さゆえにハッカー受けするような独特の構文を持っている。しかし、Tcl の構文は、ほとんどのユーザにとって奇異に感じられるものである。もし Tcl が「標準スクリプト言語」になったら、ユーザは何年も呪い続けることだろう。人々が Fortran や MSDOS やUnix のシェル構文、そして彼らがハマっていると感じるその他の事実上の標準を呪うのと同じように。

これらの理由から、GNUプロジェクトでは Tcl をGNUソフトウェアには使用しない。

Who choose which language?
誰がどの言語を選ぶのか?



単に「ある仕事をするプログラムを書きたい」のであれば、システムがサポートする言語のどれでも使える。システム設計者がどの言語がベストかの決断に口をはさまなければならない理由はない。私たちはその代わりに、それぞれのユーザが最も賢明な選択ができるように可能な限りたくさんの言語を提供することができる。GNUシステムでは、私は人々が使いたいと思う言語すべてをサポートしたい、だれかがそれらを実装すれば、の話だが。

残念なことに、機能拡張用言語はユーザが言語を選べ*ない*ケースの一つである。ユーザは、拡張したいアプリケーションやツールがサポートする言語を使わざるをえない。たとえば、PDP-10 Emacs を拡張したければ、TECO を使わなければならない。GNU Emacs を拡張したければ、Lisp を使わなければならない。

こんにち一般的に用いられている方法では、特定のユーティリティやアプリケーションパッケージを拡張するためにたくさんの言語を提供することは、容易にはできない。機能拡張用言語をサポートするということはそのパッケージの開発者に多大の作業を課することを意味している。二つの言語が少しでも適合するものだとしても、二つの言語をサポートするということは二倍以上の労力を要するだろう。実際には、開発者はひとつの言語を選ばなければならず、そしてそのパッケージのユーザは全員、その言語につきまとわれるのである。たとえば、私が GNU Emacs を書いたときには、どの言語をサポートするかを自分で決めなければならなかった。ユーザに決定権を渡す手立てがなかったのである。

開発者が Tcl を選ぶと、それはそのパッケージのユーザにとって2つの帰結を生じる:


  • ユーザは望むなら、Tcl を使うことができる。それはそれで結構なことだ。

  • ユーザは、他の言語を使うことができない。それが私は問題だと思う。



GNUソフトウェアパッケージが Tcl を使わないことをネット上に発表することで、誰もが皆、 Tcl の宣伝カー(bandwagon)に飛び乗ろうとしているわけではないこと、だから無理強いされていると感じる必要はないことをプログラマ達に示そうとしているのだ。

Design goals for GNU
GNUにとっての設計目標



あなたがプログラムを書いたり、GNUプログラムを変更するときには、何を実装すべきか決定するのはあなた自身であるべきだ、と私は思う。私は、どの言語をサポートすべきかをあなたに教えることはできないし、そうしようとも思わない。

しかし、私はあるひとつのプロジェクトとしてのGNUプロジェクトのリーダーである。だから私は、GNUオペレーティングシステムに含めるべきパッケージや、 GNUシステムの開発に向けた設計目標を決定する。

以下は、GNUシステムにおける機能拡張用言語に関して私が決定した設計目標である:


  • ユーザが（私たちがサポートする言語のうち）一つの言語を覚えればEmacsも 含めすべてのパッケージでそれを使えるように、可能な限りすべてのGNUパッ ケージは同じ機能拡張用言語をサポートするべきである。

  • 私たちがサポートする言語は、特別な弱い「スクリプト言語」に限定されるべ きではない。大きなプログラムを書くのにも小さなプログラムを書くにも同様 に適した設計の言語でなければならない。



私の判断では、Tcl はこの設計目標を満たしていない。（Tcl の著者である Ousterhout も Tclがこの目標には役立たないことに同意しているようである。彼は、これは問題にならないと思っている。私はこれは問題であると思っている。）これが、私が Tcl を GNUシステム全体に渡る主要機能拡張用言語として使わないことに決定した理由である。


  • Lispライクな言語をサポートすることが重要である。なぜなら、Lisp は、 （構文解析せずに解読できるといった） 構造化された方法でプログラムをデー タとして表現する、といったある特殊な種類の力を提供しているからである。

    • Scheme をサポートすることが望ましい。簡潔できれいだから。

    • Emacs Lisp をサポートすることが望ましい。Emacs、そしてEmacs用にすでに 書かれているコードとの互換性のために。



  • Lisp の構文を奇異に感じるユーザのために、より普通のプログラミング言語 の構文をサポートすることが重要である。

  • サポートするのが簡単であれば、Tcl もサポートすれば良いだろう。



The GNU extension language plan
GNU 機能拡張用言語計画



以下は、上述の設計目標を達成するためのプランである。


  • 決断その１。ベースとなる言語は次のような特徴を持った改良版の Scheme （modified Scheme）にするべきである:

    • 大文字小文字の区別を持つシンボル名

    • Scheme と同様Lispをサポートするために、偽 #f と空リスト () を区別しな い。

    • 簡便で高速な例外処理、そして catch & throw。

    • 他の Lisp 方言をよりよくScheme に翻訳するために、シンボルに余分にスロッ トを持たせる。[訳注:Lisp2]

    • 多重obarrayのサポート。

    • 柔軟な文字列操作関数。

    • Unixシステムコールすべて、またはほとんどへのアクセス。

    • パイプラインの生成、リダイレクトなどのための簡便な機構。

    • C言語呼び出しのための2つのインタフェース。 一つは、Cコードで任意の Scheme データに対して操作できる。 もう一つは、文字列を渡すだけであり、これは、TclのC呼びだし機能と 互換の機能。ただし、C関数からのTclインタプリタ呼出しがない場合。

    • 安価な組み込みダイナミック変数（Schemeのレキシカル変数はもちろん）。

    • ダイナミック変数からC変数への値の引き渡しのサポート。

    • アプリケーションが、アプリケーション固有の目的で Scheme データ型を追加定義できるような方法。

    • 対話的な引数読込み指定をするための場所を関数の中に設ける。

    • Scheme だけでなくLisp もサポートするために、 NIL を #fに、T を #t に 変換するようなリーダの追加機能。

    • （訳注：対話型プログラムの制御スクリプトを記述するために、Tclで使われ る）Expectのライブラリ版へのインタフェース。

    • バックトレース機能とデバッグ機能。



    これらすべてのことは、Scheme システムの中にそのままあるか、またはすでに拡張がなされてきている。課題はそれらを一緒にすることである。私たちは、 SCM を使って始める予定であり、これらの機能のいくつかをSCM に追加し、残りを Scheme で書き、可能であれば既存の処理系をそのまま使う。


  • 決断その２。他の言語は Scheme 上に実現するべきである。

    • Rush は Tcl 言語のクリーンアップ版であり、Scheme に翻訳することによっ て、Tcl自身よりもはるかに高速になる。いくつかの kludgeっぽいことが必 要なTcl の構文要素は Rushでは動かないので、Tcl オタク（aficionadoes） はこれに不満かもしれない。しかし、Rush は同じ結果を得るのに、よりきれ いな方法を提供するので、機能拡張を書くようなユーザは Rush の方を好む に違いない。機能拡張用言語を探している開発者がTcl よりも Rush を好む というのは、すでに Tcl にぞっこんでない限り、ありうることである。以下 は、Adam Sah が提供した例のいくつかである:

      • 配列引数の実体をコピーせずに渡そうとすると、Tcl では、 upvar を使う か、または配列をグローバル変数にしておかなければならない。Rush では、 単に引数を「参照渡し」（"pass by reference"）と宣言すればよい。

      • リストから値を抽出してそれぞれを別の引数として関数に渡そうとすると、 Tcl では、そのリストを使う関数呼び出し文を作ってから、これを評価しな ければならない。これは、他の引数の中に特殊なTcl構文を含むテキストが 入っているとトラブルの元になる。Rush では、apply 関数がこれを簡単か つ信頼性をもって処理する。

      • Rush は中置記法の数式や文を許すことで、"expr" コマンドの必要性を排し ている。たとえば、Tcl の計算 `"set a [expr $b*$c]' は、Rush では`a = b*c' と書ける。（Tclの構文も使える。）


        • 参考文献のいくつか:

        [SBD94] Adam Sah, Jon Blow and Brian Dennis. "An Introduction to the
        Rush Language." Proc. Tcl'94 Workshop. June, 1994.
        ftp://ginsberg.cs.berkeley.edu:pub/papers/asah/rush-tcl94.*

        [SB94] Adam Sah and Jon Blow. "A New Architecture for the
        Implementation of Scripting Languages." Proc. USENIX Symp. on
        Very High Level Languages.
        October, 1994. to appear.
        ftp://ginsberg.cs.berkeley.edu:pub/papers/asah/rush-vhll94.*


    • Emacs Lisp は、改良版 Scheme （この改良ということが重要である）に翻訳 することで効率良く実装できるであろう。


    • ちょっと見た範囲では、Python も実装に適しているようだ。私が「適してい る」といっているのは、ほとんど同一の言語が実現できるだろう、という意 味である。意味的なわずかな違いは問題にならないだろう。（誰かが、これを こまかく調べてくれるのもありがたいことだといえる。）


    • Cライクな言語の構文も、確実にこの方法で実装可能である。



  • 配布条件
    私たちは、他の拡張パッケージと有効に競合できるように、所有権を持つプログラムの中にこの改良版のScheme インタプリタを使用することを許可する。



他の言語からこの改良版 Scheme へのトランスレータはいずれも、どのアプリケーションの一部でもない。個々のユーザが、それらのどれかをいつ使うか、を決定する。ゆえに、トランスレータに対する配布条件としてGPL を使用しない特別な理由はない。だから、私たちはトランスレータの開発者に対して、配布条項としてGPL を使用することを奨励する。

Conclusion
結論



今日に至るまで、ユーザは使用すべき機能拡張用言語を選ぶことができなかった。彼らは、機能拡張したいと思うツールがサポートする言語を使うことを強要され続けてきた。そしてこれは、ツールが違えばその都度たくさんの違った言語を使わなければならないことを意味していた。

Tclを汎用スクリプト言語として採用することで、非互換性が排除できる可能性が示されている、つまり、ユーザは何もかもをたった一つの言語で機能拡張できる。だが、それでは言語を選ぶことができない。かれらは、Tcl の使用を強要され、他のものを使うことができない。

Schemeの改良版を共通機能拡張用言語にすることで、私たちはユーザに機能拡張を書くのに使用する言語の選択を与えることができる。私たちは、変更版 Tcl（Rush）、Python の変種、そして Cライクな言語を含む他の言語の処理系を作り、これらをScheme に翻訳するようにして、個々のユーザが言語を選べるようにすることができる。変更版 Tcl を選ぶユーザでさえ、この決定の恩恵を被る。彼らにとって、Scheme に翻訳される処理系によって得られる高速化は喜ばしいことであろう。

Scheme、または Scheme に似た何かだけが、この目的に役立つ。Tcl ではこの仕事は出来ない。Scheme や Python や Emacs Lisp を相応のパフォーマンスをもって Tcl 上に実現することはできない。一方、改良版 Scheme はこれらすべてをサポートできるし、他の多くの言語もサポート可能である。

共通機能拡張用言語は、改良版 Scheme にするべきである。

ボランティア募集



あなたが Scheme の処理系を熟知しており、実質のある時間をこのプロジェクトに貢献したいと思うならば、どうか
Tom Lord （lord@gnu.ai.mit.edu） にメールをお送りいただきたい。

いずれ近いうちに時間ができるだろうが、今は時間がないという方は、いつ仕事をする時間ができるかをメールでお知らせいただきたい。小規模な参加は、パッケージがリリースされるまでの間はおそらく有用ではない。

以上


  • この翻訳文は以下の履歴による。

    1. 土井（takumi@prod.csk.co.jp）と井田（ida@csrl.aoyama.ac.jp）による ものと、石野（mako@elelab.nsc.co.jp）が訳しそれに小室（mutsumi@ ori.hitachi-sk.co.jp）がコメントしたものが独立に存在した。

    2. これらを井田がまとめた。 1994.10.21

    3. RMSとのやりとりを経て、英語版11/11/94バージョンができ、井田に渡される。

    4. 土井と井田が日本語版を編集し直す。11/14/94

    5. 重政（sigemasa@alpa.csrl.aoyama.ac.jp)がHTML化した。11/16/94


  • 翻訳に対する主張。できるだけチェックはしたが、あくまで私訳であって、原文との一致性などは必ずしも責任をもてない。正確さを期すには原文を参照してほしい。 原文は、たとえば ftp://ftp.csrl.aoyama.ac.jp/pub/gnu/doc/gnuex.plan.rev や http://ftp.csrl.aoyama.ac.jp/ などにある。

投稿者 cametan_001

ラベル:

0 コメント:

コメントを投稿