YamaKen
yamak****@bp*****
2006年 4月 8日 (土) 22:21:30 JST
ヤマケンです。 At Fri, 07 Apr 2006 21:07:46 -0700, jun.l****@gmail***** wrote: > Hygienic macro の code を commit しましたが、見てわかる通りまだ何箇所 > か腐ってます (identifier の比較とか debug print とか)。 ついに来ましたね。どうもおつかれさまです。 ところで本体のmacro.cがcommitされてないですよ。 > 自分では expand-macro で展開を確認しながら scm_format を埋めて debug > してるんですが、sscm では出力が unwrap-syntax されてしまうので scope > 周りの debug が不便です。原因はguard_body() で返り値に delay() を被せ > てるからですが、どう直すべきかわかりません。というか guard 周りの code > はどうもよくわからない & わかるまで粘る気になるような外見でないので、 > 書いた人に見てほしいんですが… > ヤマケンさん unwrap-syntaxをググってみても恥ずかしながらどういう出力が欲しい のかわからないんで、現状と理想の出力を例示してもらえますか? コー ドいじりはこっちで引き受けます。 まあこんなレベルでScheme処理系のコードを書いてるんで以下のような 話になるわけです。 > そもそもこんなにいっぱい layer 要りますか? こんな不自然なコードになっているのはSRFI-34の参照実装を機械的にC にベタ移植しているからで、なぜそうしているかと言うと、Scheme処理 系の満たすべき仕様に精通しているとは言えない私がSRFI-34実装の正 しさを保証するには既存のauthoritativeなコードを主観の入り込む余 地のない形で移植するしか手がないからです。 このポリシーによって実装の正しさを保証する限り、許されるコード変 更は機械的?に等価な変換だけとなります。意味的に等価、という仕様 の解釈が入る書き換えは行ってはいけない。したがって、元のコードで lambdaを使っているところはCのコードでもlambdaを使う必要がありま す。 R5RSやSRFIのドキュメントを拝借する際に文言をいじるべきではない、 というのも同様の思想です。 > scm_s_srfi34_guard(catch, body) > { > push_handler (make_handler (catch)); > ret = scm_s_begin (body); > pop_handler (); > return ret; > } > ではダメなんでしょうか。(dynamic-wind の側で PROCEDUREP() か CONSP() > かければ make_handler() も要らないような) 現状のlongjmpな継続実装ならそれで動きそうな気もしますが、前述の ように仕様上の穴が無い事を保証できないのと、将来的にうひひな手段 でフルスペックの継続を導入したいと考えているのでこれを正式コード にはしたくないです。 が、マクロのデバッグ時専用に挿し替え用のコードを追加する分には問 題ないです。 > どうしても lambda で包む必要があるなら unwrap-syntax しない quote を作 > ることになりますが、それを採用したときには scheme code から見えないよ > うに追加しないとまずいので注意。 ------------------------------- ヤマケン yamak****@bp*****
