たとえ存在しなくとも

さて、Wyv言語が美しく簡潔であるべきだということは前回述べた通りであるが、どのようにしてそれを達成するか考えていく。

そもそも、プログラミング言語というものはどのような構成要素で成り立っているのだろうか。

この問いへの回答は粒度や視野の違いによって大きくブれるもの繰り返しが必要とか、分岐が必要とも言えるが、どちらかと言えばそれはプログラミングの本質だ。プログラミングを表現するための手法は言語それぞれへと委ねられる。プログラミングのできる言語というだけであるなら、アセンブリ言語でも機械語でもそれを満たすわけである。 [annotation: 繰り返しが必要とか、分岐が必要とも言えるが、どちらかと言えばそれはプログラミングの本質だ。プログラミングを表現するための手法は言語それぞれへと委ねられる。プログラミングのできる言語というだけであるなら、アセンブリ言語でも機械語でもそれを満たすわけである。] であるため、現状意味のないものだろう。

ここでは汎用言語として最低限必要な要素を積み重ね、統合していくことによって言語構文を成立させる手法をとることとする。

例えば、変数の定義（もしくは束縛）が実装されていない場合、少なくともこれを実用的なプログラミング言語だと言うことはできないと思われる。

同様に関数やそれに類する一連の処理の定義も必要だろう。

それでは演算子という仕組みについてはどうだろうか。1 + 1の+のことである。

考えてみればわかることだが、これは同等の機能を持つ関数addを用いてadd(1, 1)のように表わすことができる。

実際に一部の関数型言語において、+ 1 1のように演算子を表記する例もある。この場合、+が関数と全く置き換わっている例に挙げた言語では同等の機能を持つ関数addを用いてadd 1 1と記述できる。 [annotation: 例に挙げた言語では同等の機能を持つ関数addを用いてadd 1 1と記述できる。] と言えるだろう。

すなわち、演算子というものは演算で使用される関数のうち、特に一般的であるものを糖衣構文で省略したものであると言える。

従って最小限の要素で構成されていることを是とするWyv言語では、演算子という仕組みを搭載しないべきである。

――――というような判断を繰り返して、最終的に美しいプログラミング言語とすることを目指すのだ。

話を戻すが演算子というものには、機能が関数と重複しているからというだけではなく、存在そのものが厄介である場合があると考えられる。

まず、+や-といった記号そのものを限定的な存在にしてしまうということがある。

具体的に+という名前の関数を定義できない、int+floatという名前の関数も定義できない、とのようにユーザの利用できる自由な文字から演算子で使用される分が引かれてしまうわけだ。

この場合における後者int+floatでやりたいこと整数型と浮動小数点型の和算のこと。 [annotation: 整数型と浮動小数点型の和算のこと。] は演算子のオーバーロードという形で実装されていることが多い。

+という演算子の左側に整数型があり、右側に浮動小数点型がある場合、その状況に従った例外的な関数が実行されるのである。

一見便利なだけの機能であるが、これがそうとも言えない。

+という記号から読み取れる情報が余りにも少ないのだ。

整数型と浮動小数点型ぐらいであれば問題はないが、もしこれが整数型の配列同士に対して使用されていればどうだろう。

整数型の配列intary = [1, 2, 3]変数をこの場合に当てはめる。そのまま記述するとintary + intaryとなるが、この出力多くの言語では、おそらく定義されていないであろうことを注記しておく。 [annotation: 多くの言語では、おそらく定義されていないであろうことを注記しておく。] は何だろうか。

[2, 4, 6]のようにとれる一方、[1, 2, 3, 1, 2, 3]であるとも言えるのではないかと思われる。

そう、結果が一意に推測できないのである。

そのためユーザ側において、演算子のオーバーロードやそもそも演算子の定義すら禁止している、非推奨としているガイドライン整数型同士のような自明である場合のみ可能とする場合もある。 [annotation: 整数型同士のような自明である場合のみ可能とする場合もある。] は多い。

当然、言語の基礎となる部分において演算子が邪魔となることは基本的にないだろうが、ユーザ側で適切な利用がしにくい以上、メスを入れる余地は大いにあるだろう。

何を軸とするべきか

1つ1つの要素を統合するような手法とはいえ、その要素全てが演算子のように単体で完結した追加機能のようなものであるとは言いがたい。

大抵の言語では、マクロ機能を搭載することを前提とした構文にする、関数を中心として周りの構文もそれに適したものを用意する、などのように軸となる主力機能があり、それに干渉しないような設計がなされている。

Wyv言語においても、そういったベースとなる概念が求められる。

当然それは美しさ第1回で述べたようにミニマルな設計ということである。これは軸というより、肉付けの方法論と言うべきかと思われる。 [annotation: 第1回で述べたようにミニマルな設計ということである。これは軸というより、肉付けの方法論と言うべきかと思われる。] であるが、同時に抽象的なものでしかない。すなわち、もう一段階上のレベルのものが必要となるのだ。

一般にそれらは分類を明示して表記されることが多い。

C言語であれば手続き型、Javaであればオブジェクト指向などである。むしろ言語をそれら分類でまとめて扱うこともある。

今さらであるが、プログラミング言語を新しく考える際、どちらかと言えばこれら分類の先立つ方が正しい。

さて、Wyv言語がどういった方向性の言語であるか、ここまでの流れではっきりしているようには思えないだろう。

――――結論として、Wyv言語は少なくとも宣言型プログラミング言語である。

これがどういう考えであるか、どのようなメリット・デメリットがあるのか、詳しくは次回解説していく。