ゆの in Language がおもしろい理由
ゆの in Language とは、 ゆのっちのアスキーアート X / _ / X < ... を 式(yuno expression) や 文(yuno statement) などとして評価可能にして、評価時に特定のメッセージを出力するプログラムを その言語で書けるか、というものです。
このお題のミソは、ゆの式 等を構成する文字が、その言語の演算子だったり、代入構文だったりと衝突しやすいものだったりする点です。
わたしも Smalltalk で参加させていただきましたが、Smalltalk では '_' は LeftArrow (実は Smalltalkシステム内ではもともとこの文字は '←' の形に表示されます）で、C で言うところの '=' と同じ なので普通にやったら式として成立しない..というのが難しかったです。（そして召還魔法を使ってしまったりw）
* * *
ゆの in Language が盛り上がったのは、一粒で 2度おいしいからだと思います。実現が難しい言語と簡単な言語、そのどちらもあって、どちらでも参加が楽しいですし、どちらの解もおもしろい。
その言語をたしなむ程度に知っているものからは「できないよっ、これ！」と思える言語が結構多い。X が二回でてきたり、二項演算子っぽい記号ばかりだったり、シンボルになるかならないかがの微妙な境界線上にいる _ を使っていたり。お題が 言語のシンタックスに干渉するので、意味を保ったまま移植することが難しいからみんなバラバラになります。
実現のハードルが高い言語では、変態的になっていき そこに言語の色がでます。実現のハードルが低い言語では、そのこと自体が言語の変態性を如実に映し出してしまいます。あぁ、変態だらけ。自重しないJavaプログラマの遊びを堪能しつつ、Tcl のスマートさに驚きを覚えるのが両立するあたり、うまいお題だなーとおもいます。
逆にうまいお題すぎて、一流の変態さん（ほめ言葉）じゃないとおもしろいのが作れないあたり、あたしにはハードルが高かったけれど。*1
ハードルの位置が言語によって揺れ動くのがミソだとは思いますが、でもその中でも ゆの式 X / _ / X < のどこが勝利の鍵だったかというと、やっぱり お口の部分が _ だったのが勝利の鍵だったところかしらん。たとえば、ゆの in R の 'v' とかだったら *2、演算子オーバーロードがある言語ではほとんどそのまま移植可能だったり。それじゃあおもしろくない。
あたしが Smalltalk好きだから そう思うだけなのかもしれないけれど。
