2006/01/17

昨年、short filmで一緒にやった役者さんが亡くなっていたことをついさっき知った。 Entertainer Ray Bumatai, 52, succumbs to brain cancer。 撮影が6月半ばだったから、撮影のほとんど直後に脳腫瘍が再発していたのだ。

一緒に仕事をしているだけで勉強になった。もっと経験を積んでから また共演できたらいいと思っていた。 チャンスというのはいつでも一回限りなのだ。舞台でも、人生でも。

Tags: 芝居, 生活

2006/01/10

関数型言語でfor文が無いのは、という話がどこかでもりあがってるのを見た。 それについては「再帰が基本で、forはsyntax sugar」でいいと思うのだけれど、 もうひとつ、for文みたいなイディオムは、ファーストクラスクロージャと 組み合わさると、変な落とし穴を作ることがある。

ナイーブな実装を考える。

(define-syntax for
  (syntax-rules ()
    ((for (var init) test update body ...)
     (let ((var init))
       (let loop ()
         (when test
           body ...
           update
           (loop)))))))

gosh> (for (i 0) (< i 5) (set! i (+ i 1))
           (print i))
0
1
2
3
4
#<undef>

一見うまく動く。しかし、for文のbodyでクロージャが作られ、それが for文のエクステントを越えて生き延びると、困ったことが起きる。

gosh> (define p '())
p
gosh> (for (i 0) (< i 5) (set! i (+ i 1))
           (push! p (lambda () i)))
#<undef>
gosh> p
(#<closure #f> #<closure #f> #<closure #f> #<closure #f> #<closure #f>)
gosh> (map (cut <>) p)
(5 5 5 5 5)

処理の本体をクロージャにして抽象化するのはSchemerなら息を吸うように やってることだが、ループ変数を破壊的に変更してしまうとそれが 等価な変換ではなくなってしまうのだ。 些細なことに思えるかもしれないが、こういうところにトラップがあると まるで息を吸うのに不自由する感じがある。

Schemeのdo構文は再帰のsyntax sugarなのでこの問題はない。forも ループ変数を破壊的変更でなく再帰関数の引数にして持ち回ればこの問題は 起きないのだが、手続き型言語のfor文は(C++の「イテレータ」イディオムを 含めて)破壊的変更を暗黙のうちに仮定しているかのようだ。

なおCommon Lispのloopマクロやdotimesマクロはループ変数を 破壊的変更しくさるのだが、これはきっと破壊的変更の悪をプログラマに 教えんとするSteeleの親心に違いない。そうに違いないのだ。 過去に学ばないプログラマは何度も何度も何度も何度もクローズした はずの変数がいつのまにか書き換わってることに悩んで何時間も デバッグに費すのだ。おかげで昨日も締切前の貴重な時間を無駄にした。くそぅ。

Tags: Programming, Lisp, Scheme

2005/12/31

最近、故あって「1バイトの整数を読み、そこに示された数だけ4バイトの符号無し整数を読む」 みたいなバイナリデータを扱っているのだが、SRFI:42のeager comprehensionが 思いのほか便利。

(let* ((count (read-binary-uint8 input))
       (data  (list-ec (: n count) (read-binary-uint16 input 'big-endian))))
  ...)

Tags: Programming, Gauche

2005/12/31

年の瀬である。ハワイでは年に2度しかない花火解禁日のひとつであるため、 これがチャンスとばかりに人々は街が煙ですっかり覆われるまで火薬を燃やし続けるのだ。 この国にはほどほどに楽しむというたしなみはあまり無い。

去年まではまあ我慢してれば良かったのだが、今年はらむ太が居る。 寝てれば音で起きるし、起きてればびっくりして泣くし、どうやって魔の数時間を 生き延びるかが本年の課題である (許可されているのは大晦日の21時から新年の1時まで、 ただ実際は夕方から2時くらいまでやってる)。 つうかこの事態は予想できたんだからさっさと静かなホテルでも取って避難する ことを考えていればよかったんだが、例によってぼさっとしてたら、もう大晦日である。 うーん、徹夜覚悟でドライブだろうか…

Tag: 生活

2005/12/24

るびま0012号で、 えとさんがhtmlを配列を使ったツリーで扱うわびさび方式 について書いているのだが、その欠点として「(文字列操作に比べて)遅くなる」 というのを挙げている。なぜだろう。

基本的にわびさび方式はSXMLなんかと同じなわけだが、SXMLで扱う場合、 データ構造の製作中はツリー同士の結合がツリーの大きさに係わらず O(1)でできるわけで、ナイーブな文字列連結のコストに対して非常に大きな ゲインだ。それに比べたら出力時の木のトラバースなんて問題にならない ように思える。なので遅くなる理由が思い付かない。

非常に単純なケースで、 バッファリング無し、フォーマッティング無しで文字列の断片を出力してく だけの処理ならツリーで扱うよりは速いだろうけれど。 エラー時の処理とか考えたら文字列で扱う場合でもどうしても一回は バッファリングが必要になると思うしなあ。

もちろん文字列の実装がスマートで内部的にツリーを使ってるなら 話は別だが。

Tag: Programming