#peg.scm の (debug-print-width 1024) は消すかコメントアウトしたほうがいいんじゃないでしょうか？
#御意。
#V8 がまた速くなるそうな。本職の人が本気でやると進むのが早い。
##実行時最適化の正当性の検証をどうやっているのか知りたいなあ。何らかの形式的手法を使ってるんだろうか。
#実行履歴によってコンパイル後のコードが変わってゆくってことは、単純なカバレッジツールでは全てのパターンを網羅できないだろうから。Googleの開発リソースなら可能性のある最適化を全部通過できるようなテストパターンを作るツール、なんてのを作っちゃいそうだけど。
#少人数でちまちまやるとなると、むしろ形式的手法でもってどういう変化をしても正当性が保たれるっていう安心感の方がありがたいかも。
#でもJavascriptって仕様は大きくないけど、かなりたくさんのものがstatefulだから、形式的検証って大変そうだなあ。ちょい前のベンチマーク騒ぎにもあったけど、実行中にグローバルなプロパティに後からフック仕掛けられたらどうするの、とか。
#>if the assumptions in the optimized code turn out to be too optimistic.
#このあたりの話ですか。
#単純に演算途中経過の型が想定と違う場合に、コードを元に戻すみたいなのを想像しているのですが。
#その判断を本当にきちんとやっていること、をどう判断するかってことです。
#何か変な文章だな。その判断が本当にきちんどできているか、をどう検証するか、の方がいいか。
#なるほど。ごくごく単純なケース（型の組み合わせ）に限ってしかオンにならないようにして、それは自明だよね。みたいな感じなんですかね。
#それでも、そういう変化する部分がたくさんあると、組み合わせの数が簡単に爆発しますよね。それぞれの選択が完全に独立であれば独立して検証できますが、特定のレアな組み合わせの時のみ思わぬところで干渉が起きる可能性、とか恐くありません? 実装者の立場で考えると。
#実装の詳細のイメージをつかんでいないので、組み合わせ数爆発のケースが思い浮かばないです。
ちと考えてみます。
#いや私も具体例は思いつかないのですが、実装者の信条としては「今思いつく限りのケースで大丈夫」よりは「今思いつかない事態が起きても、この公理が保たれてれば大丈夫」って方が欲しくありません?
#state machineを組む時に、到達し得ない状態のところにもフォローを組み込んどく、みたいな心情です。
#到達し得ない「はず」の状態といった方がいいか。
#3つ前 s/信条/心情/ です
#ああ。それはよく分かります。
#VM のスタックレイアウトとかはまさにそういう安心感が欲しいです。
#YAGNIとケンカしますよねぇ RT : shiro: …実装者の信条としては「今思いつく限りのケースで大丈夫」よりは「今思いつかない事態が起きても、この公理が保たれてれば大丈夫」って方が欲しくありません? http://bit.ly/dHzI40 #YAGNIは使用場面の末端まで見えてる時に議論できることだと思うんですね。「実際の運用で」そんなケースは使わないし、それに当たったらその時対処すればいいだろうってわかってる。言語処理系やVMというのは(特殊用途でない限り)使用場面の限定がしづらいので、見ているスコープが違うかなと。
#むしろ、汎用言語[処理系]設計者にとっては、「そんな無茶な使い方するなんて夢にも思わなかった」っていう使い方をされるのが本望、ってところがあるからなあ。
#あああああ、昨日、rfc.jsonはAPI決まってるって書いたけど、ドキュメントを書いていたら他のモジュールとの一貫性に欠けるかなあと気になり始めてしまった。
#文字列を頭から処理してゆく系統のAPIは、入力ポートを取る関数が基本で、その上に なんとか-string として文字列を取るやつを作ってる。なので、それに合わせて変えます。
#既に今のapiに依存してるコード書いてる人いたらごめんなさい。
#YAGNI っていう言葉初めて知りました。You ain't gonna need it ですか。YAGNI で考えるときと、形式手法的に考えるときできっちり切り替えないと、混ぜるな危険ですよね。
#うーん、必ずしも排他的ではないんじゃないかとは思うけど…
#＞ 昨日、rfc.jsonはAPI決まってるって書いたけど、ドキュメントを書いていたら他のモジュールとの一貫性に欠けるかなあと気になり始めてしまった。
#もしかしたら、API変わるかもなぁと思いながらjson.scmを見ていたので、昨日書いた通り 0.9.1のリリースを待ってNendoに入れます。
#先にSekkaのライブラリとして組み込んで動作だけはunittestするんですけど。
#後で、unittestとrfc/json.nnd を Nendoに持ってくるという感じです。
#あ、排他的というわけでもないですけど、頭を切り替えないと、何をやろうとしているのかすぐに見失ってしまうので(笑)。ブロックのピースを作ってるモードと、それを組み合わせて何かを作ってるモードみたいな感じです。
#ああでも、新しい機能を考えるときは、まずごちゃっとしたでかいコードの塊を書いて、それをちょっとずつレイヤーに分けたり共通の置き換えていくことも多いから、実際はわりと境界があいまいですけど。
#その感覚はわかる＞切り替え。乗ってフルスピードで書いてる時はあんまり細かい条件って考えたくないし、検証機を満足させるために足を取られると勢いが失われちゃう。本当は一段落したところで見直して、かっちりした枠をはめて抜けが無いことを保証するのが理想的。現場ではその見直し時間が取りにくいのが悩み。
#ふっ、こいつは一本とられたな。 RT: @gengar68: (define-class <foo> () ()) (define-method foo ((self <foo>))) ((car (class-direct-methods <foo>))) で落ちる．やったー140バイト以内だ．
#--- src/vmcall.c (revision 7279)
+++ src/vmcall.c (working copy)
@@ -314,6 +314,9 @@
if (!apply_call_p) goto do_method_call;
#endif /*APPLY_CALL*/
}
+ } else if (proctype == SCM_PROC_METHOD) {
+ Scm_Error("Attempt to call a method %S without using a generic function.",
+ VAL0);
} else {
Scm_Panic("something's wrong.");
} 
Gauche > Archives > 2010/12/08