Matzにっき

_ [生活]掃除

新居の掃除、および諸事の片付け。ガスの点検、ウッドカーペットの搬入、BSアンテナの取りつけなど。 午前中いっぱいかかってしまった。しかし、それだけで疲れ切ってしまったぞ。

夜には契約関係の処理もすませる。いよいよ引っ越しの準備が整ってきた。

_ [OSS]yaccの弱点(その2)

yaccの宣言的な文法は条件が書けない。 「この条件のときはこのルールを適用しない」というような文法はありえない。

まあ、LALR(1)の性質を考えればある意味当然なので、これを弱点というのは適切ではない。 より正確には「弱点」ではなくて、せいぜい「要望」とか「欲求」とかだな。

とはいえ、 Rubyの文法には「ifなどの条件式には任意の式が書けるけどdoが来てはいけない」とか、 「メソッド引数には任意の式が書けるけどコンマを含んではいけない」のようなルールが存在する。 これに対応するためには、

• すべてのルールを展開して、doが出現しうるものとdoが出現しないものの両方を用意する(コンマについても同様)。
• lexerに手を回して予約語doに対して違うトークンを返すようにする。

前者はルールの数が増える(単純計算で4倍)ので、メンテナンスの手間がかかる。 一つのルールを修正するために、 常に4箇所(あるいはそれ以上)を更新する必要がある。あんまりだ。

現在のRubyの実装は後者を使っているのだが、 これもlexerとparserが無闇に強結合するため、メンテナンス性に問題がある。 また、yaccルールだけで文法が理解しにくいのも欠点だ。

私の知る限りでこんな無茶な要求に対応しているcompiler compilerは存在しない。

再帰下降の手書きparserなら、こんな挙動も簡単に実現できる。 「条件式フラグ」や「メソッド引数フラグ」を再帰関数の引き数のひとつに渡せば良い。 しかし、再帰下降parserもメンテしにくいことで知られているんだよなあ。

結局どれでもメンテしにくいんだったら、どれを選んでも同じってことかなあ。

_ [言語] Lightweight Language Day and Night(通称:LLDN)

Ploneを使ったこぎれいなページができている。大したものだ。

しかし、ゆうべ突然メールがきて、8月27日、28日に別の用事が入ってしまった。 こんな急な日程変更があるとは。 LLDN、昼の部だけなら出れると思ってたのになあ。

外出する用事なのでSkypeも使えそうにない。弱ったなあ。

私にとってどっちも大事だしなあ。

_ [Ruby] YARV?

Pythonの偉い人で最近Parrotにも手を出しているSam Rubyが、 YARVに関心を持っているという話。

名前にかけたジョークが出るかと期待したが、そういうのはなかったみたい(期待するものが違います)。 これで、SamはPython, Perl(Parrot), Rubyの全部を制覇か。

_ [Ruby] GCアルゴリズム

マークに用いるカラーをローテートすることで、 マークフェーズとスイープフェーズを並行に行うことができるので、 これで効率化だ、と思ったのだが、 考えてみれば、カラーを変えようがなにしようが、 これではマークフェーズとミューテーターが同時に動けない。 やはりライトバリアは必要なのであった。

スイープが並行にできるのは嬉しいことも多いだろうけどね。

自分の間抜けさ加減が悔しいので(だから研究者にはなれないんだ)、 もうちょっと考察してみることにする。

あるプロセスで割り当てられるオブジェクト数をn、 参照されなくなるオブジェクト数をmとする時(だから当然n>m)、

n小、m小

あまりオブジェクトを使わないこのタイプのプロセスでは GCは実行効率に影響を与えない。 どんなアルゴリズムを選んでも関係ない。

n大、m小

たくさんオブジェクトを作ってあまり解放しないタイプのプロセスでは 生きているオブジェクトが多いことになるので、 マークフェーズに時間がかかる。 スループットを重視するなら世代別GCが欲しくなるケース。 停止時間を重視するならマークフェーズのインクリメンタル化が必要。

n大、m大

たくさんオブジェクトを作って、たくさん捨てるこのタイプでは スイープフェーズに時間がかかる(生きているオブジェクトが相対的に少ないから)。 停止時間を意識するならばスイープのインクリメンタル化が有効。

となる。実際問題としてRubyが救済しなければならないケースはどれなのだろう。

スイープのインクリメンタル化は簡単な割に効果がありそう。 コストもあまりかからないしね。

マークのインクリメンタル化にしても、 世代別GCにしても、いずれもライトバリアが必要なので、 実行効率に影響を与える可能性がある。

_ Mostly-Concurrent Mark & Sweep GC のアルゴリズム

インクリメンタルGCのアルゴリズムの紹介。 ちゃんとスレッドを意識している。

_ [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