#カリフォルニアはもう夏時間？
#日曜日早朝から夏時間ですよ
#ありがとうございます。ハワイだと年中夏なのでピンときませんねぇ。
#今回は東海岸で飛行機に乗る朝に夏時間を迎えて、ハワイ州に夏時間が無いのがありがたかったです。どの時計を信じていいのやら w 他にアメリカで夏時間が無いのは、アラスカ州とアリゾナ州だったと思います
#>でも作業中のスナップショットとかをメインのリポジトリにpushするのも気が引ける
#躊躇なく push してます。master さえ健全であれば特に実害はないので。
#人間が読む用と機械用の2つのリポジトリに分けてるな。branch増やしすぎると視認性が落ちるので。。
#後githubだと"変更をタイムラインに載せない"方法が無いのも有る＜分割
#タイムラインを気にしたことはなかったな。レポジトリの変更を追っている人にはたしかに不親切かも。
#アリゾナはカウンティによって夏時間があったり無かったりしなかったかな。ネイティブアメリカンの自治区みたいなところだけ違っていたような。なので車であちこち寄りながら旅をしてると店とかガソリンスタンドにある時計が進んだり戻ったり
#master以外は気にしない、ってことにすれば確かに実害は無いのかもしれないけれど、branch -rしてずらずらずらっと origin/experiment_1 origin/experiment_1_fix origin/experiment_try_that origin/temp_fix とかがずらずらずらっと何十も出てきたらそれはそれでいやんな感じが。
#そうだったのですか！>アリゾナの夏時間。僕の知ってるのはTucsonだけでした。
#今調べてみたらナバホ族居住区だけDST採用、ってことのようです＞アリゾナ
#~をマクロにして(~ p foo)なら(foo p)に、(~ p'foo)なら(ref p 'foo)に展開するというのはどうでしょう? なんか紛らわしいような気もしますが。
#(dolist (slot list-of-slots) (set! (~ obj slot) #f)) みたいな使い方をすることがあるのでそれは難しいかなあ。
#こういう使い方ができるところが、専用のアクセサシンタックス obj.slot や obj->slot に勝るところでもあると思っているので。
#そうか、setterがありましたね。
#まあgetterでも、 (map (cut ~ obj <>) list-of-slots) とかわりと使うんで。
#そうか~が手続きだとcutで書けるのか。
#nmoshは~が構文なので、(map (^e (~ obj e)) list-of-slots)って書かないといけない。。
#構文にした理由って何ですか?
#~をR6RSライブラリとして実装してるので、他所のR6RSでも同じライブラリで最適化できる点。
#あと、~が使えないオブジェクトが来たときにexpand時にエラーにできるってのも有るか。
#移植性と最適化を両立するのは難しいですね。CL並にcompiler macroまで規格化されてるならともかく。ただ、本来は手続きで良いはずのものが最適化の都合でマクロになるのは、どうもすっきりしない感じがする。
#まぁ線引きかなぁ。。例えばmapとかを構文にはしないし。(なのでナイーブな実装ではmap1かどうかは実行時にディスパッチすることになる)
#R6RSのrecordが一つの例で、Will Clingerはsyntactic layerを特別扱いせずにprocedural layerからのボトムアップで組み立てても処理系ががんばればばっちり最適化できる、って主張だったんだけど、結局R6RSでは「最適化のため」にsyntactic layerとprocedural layerが別々に意味づけされて無理やりくっつけてあるような変な感じになっちゃった。
#まぁ確かにR6RS recordはなぁ。。nmoshも同様の理由で構文にしてるけど。
#マクロによる最適化って、緊急避難的にはとっても役に立つんだけど、やっぱり十分に汎用的にはならないんで(expand時に得られる情報には限りがあるため)、それをオフィシャルな最適化手法と考えてしまうことには抵抗がある。それならcompiler macroの方がまだ良いと思う(いかにも外つけのkludgeであることが一目瞭然なので)。
#どの辺が適切な線なんだろう。例えば、set!も手続きであるべきか。。lambdaやletみたいにスコープを作るものは当然構文でないと困るけど。
#代入はもともとのLispでは手続きでしたが、少しでも静的解析をしたいなら構文になってないときついと思います。どの変数が変更されているかコンパイル時にわからないとreasoningがむちゃくちゃ難しくなる。
##プロファイラ的にはコンパイラのinline-letが異常に多いから、そこで無限ループかな。。
#moshのlatest git headde
#moshのlatest git headで影響が出るとあるけれど、前のmoshでもGauche 0.9.1だとやっぱり終わらないのか、それともmoshに入った何らかの変更により終わらなくなったのか、どっちでしょ。
#Gauche 0.9だと正常なので、多分0.9.1の問題。
#今masterで試し中。
#masterでも再現するなぁ。。
#こっちでも試してみます
#moshをチェックアウトして、bootディレクトリで
#gosh -A ../misc/scripts ../misc/scripts/gen-compiler.scm compiler.scm "vm?" > compiler-vm.scm
touch free-vars-decl.scm
gosh vm.scm compile-file-without-macro baselib/match.scm
#masterだとvm.scmのcompileが終わらない模様。
#compier-vm.scmでひっかかりますね
#merge-insnのコンパイル単独で引っかかるな。
#うーんmatchの節でbisectしてみたけど不発。何らかの弾みでinline-letの呼び出し回数が爆発するような挙動では有るけど。
#とりあえずわかったのは、matchの展開形がexponentialに大きくなってることです。そのためにmatch節の数が大きくなると急速にコンパイルが遅くなります。
#(実際には、展開形は部分共有しているのでmacroexpandの出力はたいして大きくないんですが、pass1は部分共有を考えずにトラバースするので)
#多分2010-05-28の 1688aab fixes exponential expansion time in util.match が怪しいなあ。
Gauche > Archives > 2011/03/15