2007-10-02
■ haskellの動作イメージ 
どういう構造になっているか、出来るだけ単純に表すというのは、厳密にやらないとあまり意味がないけど、そういうのをぼんやり考えるのが好きだ。
haskellは、大雑把に見れば値の定義しかできない。そして、定義には順番は関係ない。
ただ、それだけだと何を表しているかさっぱり分からないので、値の定義がどこに所属するかを書ける。
実際、値の宣言と包含関係の提示が出来れば、データ構造を表すのには十分である。
データ構造が表せるだけではプログラミング言語としては不十分だ。ユーザが要求した値を返さなくてはいけない。
そのために、他の値の羅列で定義された値を評価して簡約する。簡約化の順番は、やはり定義によって決められる。
インタプリタなら、ユーザが指定する値をただ返せばいい。だが、普通のプログラムはそうなっていない。
ユーザは一つの値しか要求できず、しかもその値は破棄してしまう。
もはや、ただ値を返すプログラムは何のためにあるか分からない。
そこで登場するのが副作用である。
haskellは副作用を作るために少し細工がしてある。値を簡約化する際にアクションを起こせる。
アクションが起きると、データが書き換えられて世界が変わる。これはプログラムにとっては不都合だが、ユーザはそういった反応がなくては困ってしまう。
これを書いていたら、アスピレータっぽいと思った。水を入力して、水がそのまま出力される。この水は捨ててしまうけど、枝管の先が減圧されるという副作用が欲しい。
メインの作用は分かりやすい。でも、実際に使われるのは副作用で、それがどうやって引き起こされるのかは理解しにくい。
自作のスクリプト
haskellはデータ構造を表すのが基本だ。LISPも大体同じである。だとすれば、これらの書式はお絵描きツールのスクリプトにも流用できる。実際に絵を描くプログラムは作れるし。
しかし、そういった使い方をするには書式が一般的すぎる。haskellのコードでは絵を描いていることが一見して分かるとは思えない。
そこで、コードの書式を参考にしてスクリプトのルールを考える。やはり、プログラマは自分の言語を作れるべきなのだ。
そのためにも、良くできた言語を習得することは役に立つ。
マシン語やCの学習は、機械の動作を覚えるのには役に立つだろうが、スクリプトを作るためには役に立たないだろう。現在どちらの方が有用かというと、やはりスクリプトの作成に分があるだろう。