BBCニュースより

iPhoneでBBCニュースを読んでいたときに見つけた記事。
Japan pensioners volunteer to tackle nuclear crisis

(リンクが切れてても知りません)

僕のiPhoneにはBBCとNew York Timesのアプリがあるのだが、BBCの方が記事が短くていい感じなのでよく使ってる。
(あと、割と文章が平易なので読みやすいというのもあるが)
っで、今日上記の記事を見つけた。
訳を載せていいのか分からないので、要約だけ。
定年を迎えた元原発作業員の方が、同年代の同僚、友人に声をかけて自分たちが福島原発での作業を行うように働きかけている。論理的に60歳を越えたら放射能による癌が発現しにくいため(発現するまでに13～15年かかるので、それまでに寿命がくるという意味で)、若者よりもリスクが低い。だが、決して「神風特攻隊」ではなく、「生きて返ってくる」という意志の元で行う。
大体こんな感じ？(要約苦手な上に、日本語が出てこなくなってる・・・)

こういう方が戦後の日本を支えたのかなぁと思う一方、余生を満喫してほしいなぁとも思ったり。

syntax-rulesの挙動がおかしい件

の原因が分かった。
分かってしまえば非常に単純かつ根が深い問題である。
原因は、quoteをした際に識別子がunwrapされてしまうため、環境の参照の際に見つからなくなるというもの。
なので、quoteが現れたときにunwrapしなければこの問題はおきない。

なんだけど、syntax-rulesないでquoteしたシンボルをwriteもしくはdisplayを使って出力した際に、S式ではなく識別子が出力されてしまう。
多分これを回避するためにunwrapしたんだと思うけど、それではまずいよなぁ。
どうしたものか。

ドイツに行ってきた

この帽子ドイツんだ？オランダ！
ということでドイツに行ってきた。

といっても、ベルリンとか遠いところではなく、オランダとの国境から比較的ちかいところ。
その辺にMovie Parkなるものがあるといことで行ってきた。
どんなのかなぁと思っていってみたら、Universal Studioのドイツ版でした。サイズは日本のより少し小さいくらいか？でもローラーコースターもあったので、その気になれば比較的遊べると思う。
と思うと書いたのは、僕は無理だったので・・・いや、すべてのアトラクションがドイツ語だし。大学の時に第2外国語でとったけど、きれいさっぱり忘れたし。Ich bin ein Berliner Bal だけではねぇ・・・

そんなこんなであまり遊べず、帰りの電車の関係もありデュッセルドルフに移動。ここにはラーメン屋があるという噂を聞いたので食べれたらいいなぁ、くらいの感覚で来たのだが、これまたびっくり、一つのとおりが日本人街になってた！！
あと、なにかのイベントがあるのか、アニメキャラクターのコスプレイヤーが一杯。よくネットで海外のコスプレはレベルが高いというのを見るのだが、ありゃPhotoshopの技術が高いのか、1割くらいの当たりの写真を使ってるかのどちらかだと思う。
実際、9割くらいはGood looking boy/girlではなかったので(叶姉妹風。古い？)
目的のラーメン屋も意外とあっさり見つかり、辺りからは日本語の会話が山ほど聞こえるなか、ラーメンを注文。普通か旨い部類に入ると思うけど、あんまりラーメン通ではないのでよく分からん。
でも、醤油ラーメン、タンタン麺、餃子＋飲み物２つで29.20ユーロは高くね？

//////
投稿を分けるのも面倒なので、こっちに。

ドイツに、というときはデュッセルドルフに行ったときに感じたこと。
海外で日本人に会うとどうも変な気分になる。理由はよく分からなかったんだけど、ラーメン食べてるときになんとなく分かった気がした。
彼らも英語(もしくはドイツ語)を話す。なんとなく自分だけではないんだなぁというのを突きつけられるのと同時に何故か劣等感を感じてるんだろう。多分その劣等感は、彼らはまだ若い。僕が彼らくらいの時にはそんなことできなかった、そんな勇気もなかったというのが劣等感につながっているのだろう。
おそらく、個人的にあまり日本人コミュニティーに近づかないのは、それも理由の一つなのだろう。いや、でもアムスの日本人コミュニティーは駐在さんメインだよなぁ。それとこれは別か？郷に入って郷に従わないのが嫌いなだけかも。

//////
超個人的な話。

弱音を吐きそうになる瞬間が増えてきた。原因も分かっていて、自分ではどうしようもできない問題の部類の一つだ。これが仕事とか、言語とか、文化の違いとかならまだ楽だったんだけどなぁ。
じっとこらえるべきか、日本に帰ることを視野に入れるべきか。後者はきっと今と同じくらいに苦しいのも分かってたりするんだよねぇ。
去年応募したアメリカのグリーンカード当たらないかなぁ。(アメリカ嫌いなのにこんなことを願うあたり、かなりキテるなぁ)

マクロに潜んでいる罠

たいした物言いだがたいしたことではない。
Sagittariusで発見して、Gaucheでも再現するという不思議なバグの話。
以下のコード

(define-syntax hoge
  (syntax-rules ()
    ((_ args ...)
     (letrec-syntax 
  ((find (syntax-rules ()
    ((_ a b c)
     (next a b))))
   (next (syntax-rules ()
    ((_ a b c)
     (find a b c))
    ((_ a b)
     (print a b)))))
       (find args ...)))))
(hoge 1 2 3)

findとかnextはSSAXのマクロから取っているだけで別に名前はなんでもいい。
これを実行すると、unknown variable nextというのが出る。でも、letrec-syntaxの部分だけ取り出して実行すると動く。
原因は分かっていて、識別子の比較が弱いためにコンパイル時環境のlookupが失敗しているのだ。
不思議なこととしては、最初のhogeが展開されたときに作成される識別子は正しく作成されている(この場合は同じアドレスという意味)のに、lookup時はなぜか失敗する。
コンパイル時環境のlookupはGaucheとほぼ同じなのだが、syntax-rulesの実装はまるで違う(はず)。なのに両方でこれが発生するということは、まぁ、そこなんだろう。もしくは、syntax-rules内で予定外の識別子がrenameされたかのどちらかなんだけど。

原因を追究していたのだが、疲れたので息抜きに書いてみた。

昨日の続き

とりあえず、途中経過をダンプしてみた結果、どうもSagittariusのsyntax-rulesにおけるキーワードの扱いが間違っていそうである。

どういうことか？
昨日の段階で、arg-nameが複数回出現していると書いたが、よく見るとsyntax-rulesでキーワードを設定する箇所でばっちり全部吐き出している。つまり、展開されたarg-nameはすべてキーワードなのだ。
ということは、これはR5RSだろうがR6RSだろうがきっちり通るはずなのだが、Gaucheでは通らなかったので勘違いしてしまったということである。

マクロのパターン展開をもう一回見直すことに相成り候。。。

sxmlを使えるようにしたい

仕事柄、自分用の何かしらを書くのにXMLパーサーくらいは絶対的に必要になる。ということでSchemeでつかえるXMLパーサーということでSSAXをporting中。
必要そうなSRFI(13、14とか)を実装して、いざSSAXを流してみたらsyntax-rulesでおかしなエラーを出してくる。
エラーはパターン変数が重複しているというもの。
Ypsilonで試したらきっちり動く。でも、Gaucheでは同じエラー。
ちなみに、こんなsyntax-rules

(define-syntax ssax:define-labeled-arg-macro
  (syntax-rules ()
    ((ssax:define-labeled-arg-macro
       labeled-arg-macro-name
       (positional-macro-name
  (arg-name . arg-def) ...))
      (define-syntax labeled-arg-macro-name
 (syntax-rules ()
   ((labeled-arg-macro-name . kw-val-pairs)
     (letrec-syntax
       ((find 
   (syntax-rules (arg-name ...)
                   ;; ここが問題
     ((find k-args (arg-name . default) arg-name
        val . others)    ; found arg-name among kw-val-pairs
      (next val . k-args)) ...
     ((find k-args key arg-no-match-name val . others)
       (find k-args key . others))
     ((find k-args (arg-name default)) ; default must be here
       (next default . k-args)) ...
     ))
  (next   ; pack the continuation to find
    (syntax-rules ()
      ((next val vals key . keys)
        (find ((val . vals) . keys) key . kw-val-pairs))
      ((next val vals) ; processed all arg-descriptors
        (rev-apply (val) vals))))
  (rev-apply
    (syntax-rules ()
      ((rev-apply form (x . xs))
        (rev-apply (x . form) xs))
      ((rev-apply form ()) form))))
       (next positional-macro-name () 
  (arg-name . arg-def) ...))))))))

問題なのはarg-nameが2回出現していること。仮に展開されるとしてもarg-nameは同じものを指すので、展開後もパターン変数が重複する。仕様書を完全に理解してないけど、これはsyntax-rulesの動作として正しい。個人的に気になるのは、Ypsilonではなぜ動いたのかということと、他のR6RSの実装でもこれは動くのかということ。(もし他のR6RSの実装でも動くのなら、ちと考えないといけないかもしれない)
っで、sxmlをライブラリとして持っているGaucheはなぜ動いたのかというところを探ってみたところ、単純にバージョンが古かった。最新版といっても2004年ととても古いのだが、Gaucheのはさらに1年古い2003年のもので、make-parserはdefine-macroで書かれていた。
一応最新版と思われるbiglooで動く実装を覗いたら、そちらもdefine-mecroで実装してある。う～ん、define-macro自体はあるし、er-macro-transformerでの書き換えも非常に楽なんだけど、どうしたものだろう？
とりあえず他のも見てみるか。

VCでのコンパイルが通った

__imp_の魔の手に苦しんだが、一応コンパイルが通った。
ってか、__impl_って同考えてもVCの不具合にしか思えないくらいひどい仕様だ。これを使って開発しようという気をごっそりともってく、かなり高等な武器だともいえるか。
R6RSのテストも既知のものを除いて通らないものは１つだけという優秀さであった。
通らなかったのは、UTF16のトランスコーダーが返すEOLでcrlfが期待値なのにlfを返してるというもの。
あんまりまじめに見てないが、まぁ、割と簡単に直るだろう。
そろそろバージョン0.1.0のリリースも近いか？

かなりいいところまで来た感じ

RacketのR6RSテストのほぼすべてが通るようになった。
とりあえず通らないテストとしては、bound-identifier=?のテストの1つと、contribのテスト１つ。contribのテストは多分syntax-rulesがsyntax-caseのサブセットじゃないと通らないんじゃないかなぁと推測。
Sagittariusではsyntax-rulesはexplicit renamingで実装されているのでまぁいいかと。
bound-identifier=?のはそこまで厳密にrenamingが行われていないのと、まだまだsyntax-caseの実装が怪しいのとで原因不明。そのうち直ったらいいなぁとは思うが、この手続き自体あまり使わないので放置になるかな。
もう一つ、別環境でやったら通らなかったテストが、ポート周りのテストでstring->bytevectorとbytevector->stringを使ってるやつ。ファイルを介してテストを行うので、改行コードが処理系内部の改行コードとして処理されて通らない。ファイルを介さなければ普通にでる。気が向いたときに直そう。

ちょいちょい気になるのが、多分どこかでメモリ破壊を起こしてるんだろうなぁという出力結果が出るときがあるのだが、どこだ分からない上に、デバッガ使うと辿れない系のやつ。
見つけ次第つぶしてるけど果てしない。

ここからは愚痴。
ついでにVCでもコンパイルしようとVisual Studio 2010をインストール。っが、VCってC99に対応してないのね。結構手直しが必要になってる。特にmath.hのINFINITYとNANが面倒。あと、off_tのサイズが違うのでどうしようかな。off_t使ってるとこを全部int64_tにした方がいいだろうか？

(再)letrec-syntaxにはまる

実際にはlet-syntaxだが、どちらも同じなので。
あんまりR6RSの仕様書をまじめに読んでないことが分かってしまうのだが、こんなコードにはまる。

;; (1)
(let () 
  (let-syntax ((def (syntax-rules ()
        ((def stuff ...) (define stuff ...)))))
    (def foo 42))
  foo)
;; (2)
(let-syntax ((def (syntax-rules ()
      ((def stuff ...) (define stuff ...)))))
  (def foo 42))
foo

R5RSでは上記のコードは不正になる。let(rec)-syntaxはおそらくスコープを作るのだろう。(Gaucheで確認しただけで、R5RSを読んだわけではない)
っが、R6RSではこれはOKで、let(rec)-syntaxはbeginと同じなのだそうだ。なので、(1)の場合は単なるinternal defineに展開されると考えればいいのだろう。
explicit phasingでlet-syntaxが展開された後のことを考えればそうなのかもしれないが、(2)のケースを考えると納得がいかないなぁ。

どちらにしろ、これは直さないと。でも、とりあえず先送りにしよう。こんな書き方することはないだろうし。

Call/ccの実装が甘い

R6RSテストを通そうと足掻いているのだが、いまいち上手くいかない。
現在問題になってるのは、Cで実装されたassertion-violationがCのスタックを食いつぶすこと。
単発なら問題になることはないのだが、テストケースでは&assertionが発生してもテストを継続するため、例外 -> ハンドラ -> 例外 -> ハンドラ 以下続くとなりCのスタックを食いつぶす。
なぜこれが発生するかというと、dynamic-windがCで実装されていてかつ、call/ccがSchemeレベルの継続しか捕捉しないため、上記のようなC→Scheme→C→Schemeといった交互にレイヤーが変わるようなものに対して、継続が呼ばれた際にSchemeのスタックは戻すけど、Cのスタックはつぶされたままということになる。(のだと思う)
(Ypsilon、moshはdynamic-windがSchemeレベルで実装されているのでcall/ccで上記の問題は起きないと予測。Gaucheはそれように継続を捕捉した際にCのスタックもjmpbufという形で捕捉している、と思う)

解決方法はおそらく2つあって、dynamic-windをSchemeレベルにする、または継続を捕捉する際にCの継続も捕捉するのどちらかになるのかと。
とりあえず、後者かな。現状回避だけ見れば前者が早いのだけど、もう少し先を見据えると、dynamic-windはCで実装されててほしい気がする。

Queen's Day

昨日はQueen's Dayでした。日本でいう天皇誕生日です。
っで、フリーマーケットがあるので情報収集(たまには日本語を話したくなるともいう)も兼ねてアムステルダム南駅周辺に繰り出してみました。
こんな感じで適当に場所取りして物を売ってます。

まぁ、メインはアムス中央なのでここは割と閑散としてます。

適当に物を買いつつ、近くに日本食品を扱ってたりするスーパーはないかとか聞いたり。
まぁ、僕はあまり社交的ではないので適当ですが。後、この辺は日本人の駐在さんが多いみたいで、なんとなく空気が違った感じがしたというのもあるけど。
(自身のコミュニティからあまり出てこない感じ？)

適当に歩いた後、ついでにテレビでやっていた日本スーパーを探してみることに。
意外と近くにあったけど、さすがに閉まっていた。
来週行ってみることにする。