Matzにっき

_ [Ruby] Improvements to Ruby (Jeremy McAnally)

４月のブログコンテストのエントリを勝手に批評するシリーズ(その2)

このエントリで提案するのは、オプショナルスタティックタイピング。

def my_method(Integer param)
  puts "Well, hello!"
end

で、

def my_method(param)
  do_something if param.is_a?(String)
end

の代わりをするというもの。 自分でも似たようなアイディアについて発言したことがあるので、 気持ちはわかるが、不採用。

まず、元々のis_a?を使ったスタイルそのものがDuckTyping的見地から とても悪いスタイルである「is_a関係でのチェック」になっており、 それを推奨する言語機能を追加することはありえない。 DuckTypingを捨てたらRubyの良い点(悪い点でもあるが)を捨てることになり、 言語の性質を変えてしまう。

なんらかのタイプチェックを追加するならば、 メソッドの保有関係によって行うべきだが、 method_missingを使っているものは単純なrespond_to?を使えないことなども考えると、 これも一筋縄では行きそうにもない。

結局、「Rubyのまま」という制約の下では、 なにもチェックを行わない単純なDuckTypingが最適という結論になりそうだ。

では、Rubyではないまったく新しい(動的型)言語で オプショナルな型チェックを追加するとしたらどのようにするべきか考えてみよう。

• DuckTypingを活かすため、メソッドの保有関係でチェック。 型によるパフォーマンスチューニングについてはあきらめる(どうしても欲しければ、最初から静的型の言語を選ぶべき)。
• 保持するべきメソッドの集合を表現する「なにか」を用意する。 この何かはオブジェクトかもしれないし、そうでないかもしれない。 これを仮に「インタフェース」と呼ぶ。
• あるオブジェクトがインタフェースに適合するかどうかチェックするメソッド(or 手続き)を用意し、 型チェックではこれを呼ぶ。
• 場合によっては、コンパイラがある変数に対して呼ばれているメソッドの情報を収集し、 自動的にインタフェースを作る、型推論的なことも可能かもしれない
• method_missingはこの新しい型チェックと相性が悪いので廃止。 その代わり、respond_toとmethod_missingの両方を同時にフックするような 新しい仕組みを用意する(たとえば名前に対してlambdaを返すような)。

_ [言語] Arc in action (a.k.a. it's aliiiiive!) | Lambda the Ultimate

「Elvisは生きていた」ならぬ「arcは生きていた」。

アメリカではElvis Presleyが死んだことを認めず、 「いや、実は死んでない」とか、「実は宇宙に帰ったのだ」とか、 「ロッキー山中で目撃した」とか、よくわからない噂が流れることがあるのだそうだ。

本当か。

で、Elvisとは関係なく、 あんまり実物が出てこないものだから、きっと死んだものだと思われていた Paul Grahamのarcだが、どうやら生きていて、Y Combinator内部では実際に使われている らしい。しかも、「cons量を削減して2,3倍の高速化を実現」だそうだ。

「consを減らしたくらいで」と思わないでもないが、arcはそれ自身がCommonLispで書かれているそうなので、コンパイラとランタイム合わせたcons量は馬鹿にならないのかもしれない。

_ [Ruby] Hackety Hack

_whyによるRuby(とプログラミング？)の入門ツール。

Windows版しかないのでないので、試せなかった。 Webを見る限り、それなりに評判は良いみたい。

誰か試してみない？

評価記事も出ている。

• Hackety Hack: An Amazing Ruby Environment for Beginners