Journal InTime


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 < yx.is_lt(y)の糖衣構文で、x > yy.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

のようになってしまう。 せつない。

Tags: Ruby babel

*1  したがって、is_ltだけ定義しておけば、is_gtを定義しなくてもよい


2017-05-21 (Sun)

_ エアフィルター交換

AirTec

存在を忘れていたエアフィルターをAirTecのに交換した。 気のせいかフケがよくなったような?

走行距離: 13457km

Tags: KLX125