とくにあぶなくないRiSKのブログ

危ないRiSKのブログだったかもしれない。本当はRiSKだけどググラビリティとか取得できるIDの都合でsscriskも使ったり。

プログラム言語を考える (5)

言語内言語

言語内言語について語ると,「インラインにする必要は無い,いろんな言語をそれぞれ必要なところで使えば良い。」って反論がくることが予想できる。

確かにその反論は正しいと思う。
でも,それってみんなうれしいの?って疑問は残る。インラインならもっとうれしくなるんじゃない?とも思う。もう一言言わせてもらえば*1,すでに言語内言語を実装している言語があるってこと。
一部のC/C++処理系はインラインアセンブラを実装している。そして,それはC/C++でできないことを実現するために用いられる。高度な最適化とか,特殊な命令の実行だとか。じゃあ,インラインアセンブリはどのくらい用いられているだろう?
局所的に用いられるに違いない。スピードが問題になる箇所や特殊な結果が欲しい箇所だ。この部分だけのために,C/C++とアセンブリをどのようにくっつけるかを考え,アセンブリを準備し,アセンブリのソースファイルを用意し,ソースをアセンブルし,C/C++のオブジェクトファイルとリンクし…としたいだろうか?
アセンブリの規模が大きくなれば,その手順によるコストの比率は全体から見れば小さくなるので「それぞれ」でもいいだろうが,私が考える限り,局所的に他言語を用いることのできる言語内言語のメリットはある。
文法(シンタックス)についてはまだ考えていないのだから,(必要ではないとしても)できることは多い方が多くの人が幸せになるはずだ。

シェル

C/C++インラインアセンブリなんかとは比較にはならないレベルで言語内言語を実装している言語がある。それは OS のシェルだ。
Unix 系のいくつかのシェルでもいいし,Windows な cmd.exe でもいい。ぶっちゃけ command.exe でもいい。Perl がインストールされていてパスが通っていればシェルスクリプトあるいはバッチファイルから Perl を利用できる。Windows に Cygwin が入ってるなら,cmd 上から bash を利用できるし,その逆もできる。この言語内言語のすばらしさは,GUI Only な人には分かるまい。

脇道

例によってまた脇道である。いつぞや考えたプログラム言語とハードのレイヤーとの対応の事だけど,OSの仕事ってのは,まさに各レイヤーをつなぐ事だ。そして,結果として人を幸せにすることだ。OSの設計と「はりふ」の設計には通ずるものがあるな。実際,シェルだって OS の一部だし,無関係とはとても思えん。むしろイコールじゃないのか?

system

話を戻す。言語内言語の話だった。
いいか?よく聞くんだ。プログラム言語Cインラインアセンブリという限定的なものではなく,大分前から文字通り言語内言語を使えるんだ。もちろん条件付きではあるけどね。
それは system 関数によって実現できる。system 関数はシェルを呼び出す。そのシェルは言語内言語機能を持っている。プログラム言語Cでも簡単に正規表現を使えるんだ。すばらしいじゃないか!いい感じで,電波が出てきたぜ!言語内言語を halif に組み込むことは決定だ!


次は何について考える?そうだな,候補としては「抽象化と最適化」,「データとプログラム」,「自由と制限」,「各プログラミングパラダイム,マルチパラダイム」あたりがいいかな。あー楽し。

*1:おっと,馬から落馬。追記:おもしろいの見つけた。「防犯対策」→アップ↑ ̄ ̄ ̄ダウン↓___