lamdaの記号をどうするかという問題はあるものの、 実際に動かしてみないとイメージが掴めないので、 ごそごそとparse.yをいじってみる。 半日ほどのハックで動くようになった。
NODE_ARGSの構造が変化してしまった。 Yarvに迷惑がかかるかな。
とりあえず、動いてはいるようだ。 これをコミットしたものか。
で、実装した新lambdaはlambdaに対応する記号の部分だけ lexerをいじれば簡単に変更できる。
今のところ、最初の案の通り「->」を使っているのだが、 「関数型言語の文化圏からすると引数の前に -> が来るのは激しく気持ち悪い」という指摘も受けている。ここで案についてまとめておこう。
もともとの案。実はPerl6から来ている。Perl6ではRubyのブロック相当を実現する文法として、 「->」が使われており、たとえばfor文が
for list -> x { ... }
のような文法になっている。「->」でパラメータに代入しているというイメージか。 また、ここから派生してクロージャは「-> x { ... }」で表記している。
Perl6はRubyと文化圏が近いため、参考にするのは悪くない、ような気もするが、 そもそもPerl6はいつ実用化されるのか、とか、使われないんじゃないだろうか、 とかいう懸念もある。この記法はブロックとして使われるときには(代入を想起させるので)、 そんなに悪くないんだけど、単体のlambda式として考えると
proc = ->(x, y) { ... }
という記法で、あんまり関数っぽくない。
Haskellではlambdaにバックスラッシュが用いられている。 これは「＼」がギリシャ文字のlambda(λ)に似ているから、らしい。
それは分からないでもないが、UNIX文化圏ではエスケープの意味が強すぎるので 受け入れられないような気がする。
proc = \(x, y) { ... }
では、エスケープされた括弧というイメージが大きすぎるのではないか。 文化の違いというのは大きいものだ。
あと、フォントによっては「¥」マークになってしまうのも痛い。
じゃあ、バックスラッシュ二つ重ねるのはどうだろう。
proc = \\(x, y) { ... }
ひとつだけよりはマシのような気がする。が、
ary.each \\(x) { ... }
という使われ方を考えると、視覚的なヒントが少な過ぎる。 この記号を採用した場合にはlambdaとしてだけ使い、 ブロックの記法には使わないようにすべきだろうな。
この案も「¥」マーク問題を無視できない。
ま、結局はブロックとlambdaのどちらに重きを置くかという点のような気がする。 もともと現在のlambdaのパラメータ指定がメソッドの引数と同一でないのが最大の不満だったので、 lambdaの方を強調すべきなのかもしれないが。
現時点では、各案に順位を付けられるほど考察が進んでいない。
長女の吹奏楽の発表会で県民会館へ。
ついこの間始めたばかりなのにもう発表なのか、と思わないでもないが、 一生懸命やっているようだった。もっとも、彼女の演奏している音が識別できたわけではないが。 団体だとその辺は有利だよな。本人曰く、「めっちゃ緊張した」そうだが。
同じ1年生でもパーカッションの娘は、出来がはっきりわかっちゃうから大変だよなあ。