Hatena::Grouphaskell

knenetのhaskell手記

2007-10-02

haskellの動作イメージ 17:28 はてなブックマーク - haskellの動作イメージ - knenetのhaskell手記

どういう構造になっているか、出来るだけ単純に表すというのは、厳密にやらないとあまり意味がないけど、そういうのをぼんやり考えるのが好きだ。


haskellは、大雑把に見れば値の定義しかできない。そして、定義には順番は関係ない。

ただ、それだけだと何を表しているかさっぱり分からないので、値の定義がどこに所属するかを書ける。

実際、値の宣言と包含関係の提示が出来れば、データ構造を表すのには十分である。


データ構造が表せるだけではプログラミング言語としては不十分だ。ユーザが要求した値を返さなくてはいけない。

そのために、他の値の羅列で定義された値を評価して簡約する。簡約化の順番は、やはり定義によって決められる。


インタプリタなら、ユーザが指定する値をただ返せばいい。だが、普通のプログラムはそうなっていない。

ユーザは一つの値しか要求できず、しかもその値は破棄してしまう。

もはや、ただ値を返すプログラムは何のためにあるか分からない。

そこで登場するのが副作用である。


haskell副作用を作るために少し細工がしてある。値を簡約化する際にアクションを起こせる。

アクションが起きると、データが書き換えられて世界が変わる。これはプログラムにとっては不都合だが、ユーザはそういった反応がなくては困ってしまう。


haskellプログラムはこんなイメージだろうか。

これを書いていたら、アスピレータっぽいと思った。水を入力して、水がそのまま出力される。この水は捨ててしまうけど、枝管の先が減圧されるという副作用が欲しい。

メインの作用は分かりやすい。でも、実際に使われるのは副作用で、それがどうやって引き起こされるのかは理解しにくい。


自作のスクリプト

haskellはデータ構造を表すのが基本だ。LISPも大体同じである。だとすれば、これらの書式はお絵描きツールのスクリプトにも流用できる。実際に絵を描くプログラムは作れるし。

しかし、そういった使い方をするには書式が一般的すぎる。haskellのコードでは絵を描いていることが一見して分かるとは思えない。

そこで、コードの書式を参考にしてスクリプトのルールを考える。やはり、プログラマは自分の言語を作れるべきなのだ。

そのためにも、良くできた言語を習得することは役に立つ。

マシン語やCの学習は、機械の動作を覚えるのには役に立つだろうが、スクリプトを作るためには役に立たないだろう。現在どちらの方が有用かというと、やはりスクリプトの作成に分があるだろう。