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系のライセンスが良いと思う。
失敗。いろいろとタイミングが悪かった。非っ常に残念だ。 先方にも申し訳ないことをした。