HSP作者さんは言語を作りたかったんじゃないんじゃないかなぁ。
まったくその通りだと思う。私は言語屋なんで言語のことしか見てないけど、 実際は彼が作りたかったのは「プログラマブルなツールジェネレータ」くらいじゃないかと。
で、言語(の文法)にはあんまり興味がなかったんで、 慣れ親しんだN-BASIC(あれ、N88-BASICかな)に類似の文法を実現したと。
すべての人に、言語文法に対して愛を持て、と言うこと自体がムチャな要求なので、 それはそれで当然のことなのかもしれないが、 なんかあんまり考えられていない文法の言語が量産されるのは、見ていてつらい。 余計なお世話だけど。
とすると、こんなのはどうだろう。
「プログラマブル」という機能を提供する、言語ツールキットがあって、 プログラマブルなツールを提供したい人は、そのツールのAPIに従って 機能をドロップインすれば、あら不思議、プログラマブルツールの出来上がり、 というのは。
発想としては、Tclとか、Guileとかに似ていないこともない。 だが、これらでは十分ではない。言語ツールキットの要求仕様はこんな感じではないだろうか。
自然な文法
BASICのような古臭い文法でも、 Lisp(S式)のような「(優れているが)特殊な印象を与える」文法でもないものを。
優れたAPI
ツールに組み込むことを念頭に置いた使いやすいAPIを提供する。
優れた移植性
WindowsでもUnix系OSでも動作する移植性。 なに、どうせ移植性が問題になる部分は、 「ドロップイン機能」の方で実現されるのだから難しいことではない。
リファレンス実装
「これを使えば可能です」は十分ではない。 「このツールは使っています」ということを示せねばならない。
性能
まあ、そこらの言語と同等であれば十分だけど。
TclやGuileは「文法」の点で不利だ。Tclの文法(というか実行モデル)は、 ある意味古臭いし、GuileのS式はほとんどの人にはとっつきにくい。
同じターゲットを目指してそうなものとして、Luaもあるが、 これもパッとしない。tableというモデルがいけないのか、 それとも別の原因があるのか。
探してみると、他にもSmallとかいくつも類似のプロジェクトがあるな。 大成功しているものが見当たらないのは、既存のプロジェクトがなにか見落としているのか、 それとも、この種のアイディアにはなにか致命的な欠陥があるのか。
なお、Rubyはこの目的にはふさわしくない。
言語仕様
Rubyの「全部メソッド」というモデルは強すぎる。 通常の手続きも必要だろう。「全部オブジェクト」は問題ないと思う。
インタプリタ実装
Rubyインタプリタは組み込みのことを十分に考えて実装されていない。 この点についてはTclの方が100倍優れている。
ライセンス
独自ライセンスのRubyは組み込みに関して安心感がない。 実際には問題は発生しないと思うけど。 ここは制限の少ないBSD系のライセンスが良いと思う。
This work is licensed under a Creative Commons License.
sendmailの設定ファイルのことですかね？
同じような事を目指したのが Squeak なんじゃないでしょうか。<br>Squeak の場合は、Class や Method などが(一般の人には)見えませんけど(ｗ。
私の印象だとSqueakは正反対なのですが。<br><br>Squeak(というかSmalltalk)はなんでも自分の世界に包み込んでし<br>まうんですが、今回話しているのは「外の世界にプログラマビリ<br>ティ」を提供するものです。<br><br>あと、Smalltalkは(私の基準では)ちょっとモデルや文法がエキセ<br>ントリックに過ぎるかも。初心者だけが対象ならぜんぜん問題ない<br>んですけどね。
ドロップインの意味が十分理解できないのですが、これは関数の呼出し規約だけ統一して、言語の文法を取り換え可能にという理解でよろしいのでしょうか？<br># 言語ツールキットに載せる各言語エンジン<br># (ex: C/C++,Ruby,Perl,LISP,etc,,,)<br># だけカスタマイズして載せ替えると言語処理系が出来上がり、<br># それぞれの処理系で作った関数は何も考えずにリンク可能とか？
ここのインタビューに書かれているとおりだとおもいます。<br><br>窓の杜・作った人は？ ＨＳＰ作者おにたまさん<br>http://www.forest.impress.co.jp/article/2002/01/17/whocreate3.html
文法を切り替えるなんてだいそれた事は考えてません ＞ kouさん<br><br>「文法切り替え」は一見魅力的に見えるけど、手を出すと失敗する<br>アイディアの代表格ですよね。<br><br>考えているのは要するに「まともな実行モデル」と「マシな文法」<br>でTclのようなものを提供したいんですよ。もうひとひねりないと<br>成功しないかもしれませんが。
文脈から、keisuken さんのおっしゃっておられるのは、Smalltalk <br>ではなく、Squeak システム上に実装されている Squeak eToys とい<br>うプロトタイプベースで強い型付きのビジュアルスクリプト言語の<br>ことではないかと想像します。念のため。<br><br>もっとも eToys も Smalltalk 言語同様、Squeak システム専用に作<br>られた言語なので、“「外の世界（Smalltalk システムを単に言語<br>処理系としたとき、それを動作させるのに用いている Linux などの <br>OS のこと、ですよね？）にプログラマビリティ」を提供するもの”<br>ではない、という結論に変わりはないと思いますが。
まつもとさんがおっしゃるような「言語ツールキット」を可能とする環境として、.NET Framework/Rotor/Mono が最適ではないでしょうか。
文法のデザインは、ハフマン符号化のようなものかもしれません。基本は「良く使うものを書きやすく」ですが、それをすると、その影で書きにくくなる部分があります。例：演算子など、lexerにとって特殊な意味をもつ文字を増やす→識別子にその文字が使えなくなる。中置記法を使う→その演算子が２項演算に限定される(haskell方式を使わない限り)。そもそも、「良く使う」ものが特別扱いされているということを覚えておかねばならない、等。最後のものは、言語設計者の考える使用法と、言語ユーザの考える使用法がずれている場合に、ユーザの負担になります。<br><br>使う人のバックグラウンドや対象となる問題領域にかかわらない、グローバルに最適な「良く使うもの」を決められるとするか否かで、立場が分かれると思います。<br><br>そのようなグローバルな最適点は無くて、最適な解は個々の問題を解くプログラマのみが知っている、とする立場に立つと、「良く使うもの」を言語設計者が決め過ぎるのはpremature optimizationになります。この立場では、なるべく文法規則を単純で一様なものにしておき、必要ならプログラマが問題に合わせてカスタマイズする、という方向になります。これがLispやTclの立場だと思います。<br><br>一方、問題の対象が限定されればされるほど「良く使う」操作に関して予測が立てやすくなるので、最適化が成功しやすくなるでしょう。シェーダー言語に、汎用的配列とは別に2〜4要素のベクタと配列を扱う文法レベルでのサポートがあるのは大いに意味があります。<br><br>問題の対象を一切限定しないで、グローバルに最適な文法をデザインできるか、はかなり未知なる領域だと思います。
sumin さんの創造であってます。> Squeak<br>言語ツールキットに関してはたんなる理解不足でしたので気にしないでください。