My life as an APE

●Twitterを始めてみた
（一部で）噂のマイクロブログ・サービス、Twitterを始めてみた。
http://twitter.com/hakuroh

世の中に叫びたいどうでも良い事で、かといってBlogにするのも面倒な一言を気楽に更新するのに便利だ。
例えばこれまでの更新はこんな感じだ。

・ものみの塔の勧誘フォーマットは日米共通らしい 06:30 PM October 21, 2007
・髪の毛が伸びすぎて破綻　切りたい。 08:57 PM October 19, 2007
・ベトナム化するアリとの戦い 10:41 AM October 15, 2007

どうしようもない無意味感が心地よい。
こうした内容を遠い宇宙に向けて送信するサービスというのはあっても良いかもしれない。月々$4.99くらいなら有料でも良い。いつか遠い宇宙人が自分の垂れ流しメッセージを受け取るかもしれないとしたら結構面白い。

●あかふく
日本国では伊勢の赤福が店頭で買えなくなっているらしい。国民的損失である。

賞味期限というものはそんなに厳密に扱うべきものなのだろうか？
アメリカンなスーパーではカビのよく育ったニンジンを買うことができるし、近くの日系スーパーでは日本直輸入製品がたいてい賞味期限ギリギリで（またはOverでも）取り扱っている。
そうしたとき食べれるかどうかを五感で確かめるのは、生き物としての生活の知恵ではないだろーか。
自分の僅かな経験から言えば、あかふくは相当日を置いても大丈夫だ、無問題。
周りのあんこが緩衝材となって内部の本体を温存していてくれるため、ある程度の日数は鮮度が保たれる、気がする。
#あんこが本体か、もちが本体か、という点についてはまた別の話。

はなしのすり替えではあるが、日本のメディアにおかれましては、あかふくの事を気にするよりは、近海もの大型魚類の水銀含有について気にしたほうが良いだろう（特に妊婦の方と子供さん向け）。

お魚安全チャート
http://www.oceansalive.org/eat.cfm?subnav=healthalerts

では牛はどうか？　チャイナ野菜はどうか？　ということになるとよくわからない。
五感と第六感を活用して自衛するしかないだろう。

ECMAScriptの奇妙な仕様のひとつに’Auto Semicolon Insertion’がある。要するに行末の';’が有っても良い、無くても良い、という地球に優しく、パーサにめんどくさい仕様だ。

例）
foo = bar + 1; //あっても良い
foo = bar + 1 //無くても良いよ

この機能が発動する条件は、EMCA262の7.9節でこう定義される

トークン(文字のかたまり)を左から順番に見てって、文法的な悪玉トークンがあらわれたとき、
1)悪玉トークンの前に改行がある
2)悪玉トークンが'}'
3)悪玉トークンでないけど、改行不許可の場所に悪玉改行がある
のいずれかのときに';'が挿入される

ただし、for文の';'の代わりとしては挿入されない
また3)の改行が許されない場所とは
・後置の++/--
・ラベル付きのcontinue
・ラベル付きのbreak
・パラメタ付きのreturn
・パラメタ付きのthrow
の5つ、改行すると別の構文として解釈できてしまう場合だ。

例えば
{
　foo
　++
　bar
}

この場合
　{
　foo++;
　bar;
　}
となる。

なんというかC++に似た構文に自由度を一滴垂らしたら色々収まりが付かない仕様になってしまっている。

●ラベル＋式＋{}の怪しい関係
上記の条件によると
{
foo:
　　bar = 0
}

なんかは、普通のラベル＋式ステートメントではなくて、
プロパティ初期化つきのオブジェクト・リテラルとして還元される。
（ただしオブジェクト生成後の代入なし）
なぜなら、最後に出てくる'}'は（オブジェクトリテラルの構文として）悪玉トークンではなく、';'は挿入されないからだ。
#オブジェクトリテラルの構文は
#{ プロパティ名:値の式 [,プロパティ名:値の式] }

この場合でも、プロパティの初期化子の式は普通に実行されるので動作上の影響は無い。また（大抵は）インタプリタ/コンパイラが代入の無いオブジェクト生成は省略してくれる。
#ただし、ラベルと思って定義したfoo:がラベルとしては定義されないため、頑張ればラベル付きbreak等の文で奇妙なエラーを起こすこともできそうだ（が、そもそもラベルを使ったECMAScriptはみたことない）。
#なにより、変な風にコードが解釈されてるのは不気味

ためしにJScript.Net8.0でJscriptをコンパイルし、CIL（バイトコード）に変換してみる。JScript.netの環境では、Jscriptのバイトコード変換後の結果が調べられるので、何かと役に立つ。

{
foo: bar = 3
}
IL_0003: ldc.i4.3
IL_0004: conv.r8
IL_0005: stloc.0

ためしに
{
foo: bar = 3,
foo2: bar2 = 3
} //プロパティふたつのオブジェクトリテラル

だとコンパイルエラー。

Jscript.Netではこうした場合、普通にラベル＋式として解釈されているようだ。なんだか仕様と違う気がしないでもないが、見なかったことにする。

今日も平和だ。
つづく

最近何かとECMAScript（エ熊スクリプト）の仕様を触る機会が多い。仕様書を吟味してみると、C++的パラダイムからやってきた異邦人には何かと驚きのことも（JScripterな方々には当たり前のことも多いだろうので、コメントがあれば教えてください）。

ECMAScriptの仕様は一連のECMA仕様書によって定義されている。

ECMA262　第３版ベース仕様書
http://www.ecma-international.org/publications/standards/Ecma-262.htm

ECMA290　コンポーネント仕様書　XMLのインタフェースなど定義
http://www.ecma-international.org/publications/standards/Ecma-290.htm

ECMA327　コンパクトプロファイル定義　組み込み向け軽量実装
http://www.ecma-international.org/publications/standards/Ecma-327.htm

ECMA357　XML拡張　って実装されているのだろうか
http://www.ecma-international.org/publications/standards/Ecma-357.htm

ECMAScript 第４版Wiki　正式仕様化希望
http://wiki.ecmascript.org/doku.php

これらの仕様書、とくにベース仕様書は、仕様書としては（控えめに言って）かなり読みにくい部類だ。例えば言語の挙動が自然言語（ここでは英語）で定義されているのだが、それが一層解りにくくしている。
また、Closureなどの重要な概念が明記されておらず、変数スコープの仕様をじっくり300回ほどは読み込んだうえで拡大解釈しないといけない。腐ってると言ってもよい、多分。

言語仕様そのものも（再び、ライトウェイト言語としては普通なのかもしれないが）なかなか驚かされることが多い。仕様の成り立ちからしてすでに実装済みのJScriptとJavaScriptの共通部分を定義という、実装ありきの涙ぐましい状態からスタートしていることもあるだろう。苦労している様が伺われる。ガンバレECMA!!

その１　switch文はif文の羅列と同じ
ECMAScriptのswitch文ではcaseブロックの条件に式が指定できる。定数ではなくて、式だ。そもそもECMAScript(3rd)では定数の概念が（組み込みオブジェクトのReadOnlyプロパティを除いて）存在しない。
式が記述できることで何ができるかというと、下記のようにswitch文を変幻自在に書くことができる。

/*見難いのでbreak;は省略*/
switch( foo ) {
case 0: //まぁ普通
case bar: //まだ普通
case bar+2: //まだまだ普通
case bar+foo: //あんまり見たこと無い
case "bar": //これは良いものだ
case func(): //何がしたいのかよくわからない
case { bar: func() }: //さらにわからないことに
case 0: //デジャビュ？
case 0: //マトリックスの中に居るのか？
default:
}

といった風に条件式を重複もなんも気にせず記述できる世界だ。
自由だ・・・
また仕様上、条件式は実行時に、律儀に記述の順番どおりに評価されなくてはならないため、上記の文はif文での下記の記述と等しくなる。

if( foo == 0) { }
else if ( foo == bar ) {}
else if ( foo == bar + 2 ) {}
else if ( foo == bar + foo ) {}
else if ( foo == "bar" ) {}
else if ( foo == func () ) {}
else if ( foo == { bar: func() } ) {}
else if ( foo == 0 ) {}
else if ( foo == 0 ) {}
else {}
//ｷﾞｬｰ

caseブロックが50個くらい並んでいたりすると、後になればなるほど実行速度が遅くなり、途中で条件式が重複してたりするとよくわからないことになりそうだ。
また、式の評価をまじめにしないといけないので、テーブル参照生成等のコード生成最適化がしにくい。
#重複する式を削除、警告の出力等は可能だろう。
#追記：コンパイラ最適化としては、全てのノードがLiteralのときだけ
#hash参照にするという特殊ケースが考えられるが、
#どれくらい頻繁なケースかよく解らない。もしかするとこれが主流？
#また、第４版仕様のconstを使うとよいだろう


割と恐怖の仕様で、これは「switch」とは言わないのではないか～、とか、IEの適当な実装が既に出回っていて修正不可能だったのではないか、などなどの想いが胸をよぎる。

つづく