2001-05-21 (Mon)
_ jus関西シンポジウム
見に行って来た。
砂原先生の未踏都道府県には鳥取がふくまれていたらしい。 ちなみにいまだに島根は未踏都道府県。
IPCarプロジェクトでは新型ソアラ(屋根が開くやつね)にBSDをのせるんだって。 すてきだ。
[ツッコミを入れる]
2004-05-21 (Fri)
_ レシーバとパラメータの評価順序
今回の投票（Ruby: recv.m(a1, a2, ..., &block) の評価順序が a1, a2, ..., recv, block という順序になって許せるか？）は、左から右へ、の原則が嫌だ、というわけではもちろん無くて、「仕様を無視してでも高速化のためには妥協しても仕方がない」部分かそうでないか、ということだと思っております。で、どっちとも取れなくて悩む。
1+2 で 2,1 と評価されるのは気持ち悪いし、やっぱり recv は先にくるべきかなぁ、と揺れ動く今日この頃。
[だいありーより引用]
まつもとさんと話したら、自分の処理系では評価順序を保証したいけど、言語仕様としては 処理系依存でも許せるかなあ、とおっしゃってました。 あと、メソッド探索に失敗した場合に、引数は評価されるべきかどうかも処理系依存で いいんじゃないかとか。
今の処理系で評価順序を保証しているのは、Satherの影響らしい。
ちなみに、Satherではx < yはx.is_lt(y)の糖衣構文で、x > yは
y.is_lt(x)のようにオペランドを入れ換えることになっている
*1
のだが、その場合でも評価順序はx -> yでなければならないと
規定されている。
.NETにはswap命令がないので、babelでは
x: BOOL := 2 > 1;
は、
IL_0000: ldc.i4 2 IL_0005: stloc.1 IL_0006: ldc.i4 1 IL_000b: ldloc.1 IL_000c: call bool class [bscore]'Babel.Base.INT'::'is_lt'(int32, int32) IL_0011: stloc.0
のようになってしまう。 せつない。
*1 したがって、is_ltだけ定義しておけば、is_gtを定義しなくてもよい
[ツッコミを入れる]
