YamaKen
yamak****@bp*****
2006年 4月 27日 (木) 16:01:30 JST
ヤマケンです。反応遅くなってすいません。 At Sat, 08 Apr 2006 16:08:30 -0700, jun.l****@gmail***** wrote: > > YamaKen <yamak****@bp*****> writes: > >> 自分では expand-macro で展開を確認しながら scm_format を埋めて debug > >> してるんですが、sscm では出力が unwrap-syntax されてしまうので scope > >> 周りの debug が不便です。原因はguard_body() で返り値に delay() を被せ > >> てるからですが、どう直すべきかわかりません。というか guard 周りの code > >> はどうもよくわからない & わかるまで粘る気になるような外見でないので、 > >> 書いた人に見てほしいんですが… > ヤマケンさん > 端的に言えば > > sscm> (define-syntax macro > (syntax-rules () > ((_) sym))) > > という前提で、現状 > > sscm> (expand-macro macro) > sym > > となってるのが > > #<farsym 0 sym> > > になってほしいということです。 とっくに見てると思いますが、r3289で対応しておきました。 > > こんな不自然なコードになっているのはSRFI-34の参照実装を機械的にC > > にベタ移植しているからで、なぜそうしているかと言うと、Scheme処理 > > 系の満たすべき仕様に精通しているとは言えない私がSRFI-34実装の正 > > しさを保証するには既存のauthoritativeなコードを主観の入り込む余 > > 地のない形で移植するしか手がないからです。 > > > > このポリシーによって実装の正しさを保証する限り、許されるコード変 > > 更は機械的?に等価な変換だけとなります。意味的に等価、という仕様 > > の解釈が入る書き換えは行ってはいけない。したがって、元のコードで > > lambdaを使っているところはCのコードでもlambdaを使う必要がありま > > す。 > > > > R5RSやSRFIのドキュメントを拝借する際に文言をいじるべきではない、 > > というのも同様の思想です。 > > SRFI 文書の参考実装を忠実に C に転写するのは構いませんが、それが参考実 > 装の code (である list 構造) を C data で表現するという意味であれば C > 路線を捨てて core 以外 scheme で書いた方が確実で効率的です。(SRFI も殆 > どコピペで済むし、read の overhead が嫌ならScheme→C converter を > scheme で書けば良い。多分 50 行以内で済むでしょう。) そんな風に既成の枯れたライブラリを使いまわしたいというのがSIODに 代わるScheme処理系を求めたそもそもの動機なので、私はむしろCのコー ドを減らしたい派です。太田さんの方針もあるのでR5RS部分については library procedureも少ないことだしall Cでいいかと思っていますが。 一方、SRFIについては必要性が無い限りCで実装する事には積極的に反 対です。今までに書かれたmodule-srfi*.cはSchemeでは書けなかったか、 pure Schemeでは著しく効率が落ちるものだけです。SRFI-34もCで書き たいわけではなく、実装時点でマクロを利用できなかったからああなっ ただけです。 太田さんが書きかけのmodule-srfi1.cは上記に当てはまりませんが、 uimではSLIB実装の方を使うつもりである事は最初期から繰り返し表明 しています。効率のために一部のprocedureをCで独自実装する事は考え られますが。 井上さんがマクロを実装してくれたおかげで既存のSchemeによるSRFI実 装を流用できる幅が大きく拡がったわけですが、今あるmodule-srfi*.c は効率面重視の選択肢としてそのまま併存させるつもりです。一定の品 質も確保できていると考えているし、マクロはいらないがSRFI-8は欲し いというような場面もあると思うので。 > それより、 > > > Scheme処理系の満たすべき仕様に精通しているとは言えない私がSRFI-34実 > > 装の正しさを保証するには > > という部分が非常に気になります。言葉の齟齬がある気がしますが、もしこれ > が、ヤマケンさんが自分でよくわかってないものをよくわからない code を拝 > 借して形にしようとしている、という意味であれば危険極まりないと思います。 > 他人 (∋過去の自分) の実装に正しさを求めるなら、その実装の働きを理解し > ないと正しくコピペすることもできません。 さすがに文書による仕様そのものの規定とコード各部の意味、実行の流 れぐらいは理解してから移植しています。ブラックボックスのまま変換 したわけではありません。ただし、この指摘で痛いところを突かれたの は確かで、コード各部がなぜそのような実装になる必要があるのかとい う各種要求仕様の洗い出しや、それを転じた最適化の余地の把握は十分 にできていません。 がしかし、これらの考察不足によりバグを見逃している可能性も無いと は言えませんが、想定される利用範囲についてはテストを書いて動作を 検証済なので、品質はSigScheme全体の中ではむしろ高い方と想定して います。他の部分を置いてここにこれ以上の労力を割くのはナンセンス です。 上記の考察や最適化を行っていないのは、[Anthy-dev 2500]で指摘され たようなScheme処理系に関する知識・経験の不足による見落としの可能 性を考えての事です。したがって、環境、継続、クロージャ等のインス タンスの生成・操作は参照実装と同じタイミングで行うようにしていま す。一方、それらのパラメータが少なく、影響範囲と等価性を確信でき る末端のコードについては最適化を行っています(call-with-valuesの 省略等)。これは「SRFI-34仕様を解釈した上での意味的に等価な再実装」 ではなく「参照実装のコード片の機械的な変換」の範疇のつもりです。 また、効率を追うにしても将来的に何らかのマクロ機構の利用が選択肢 に入ってからでないと最善の結果にならないと考え、苦労して最適化を 行う価値が無いとの判断もありました。 ではマクロが使えるようになった今はどうかというと、まだmacro.c等 の実装の整理や(フットプリントを含めた)パフォーマンスの分析等が終 わっていないので、当面はmodule-srfi34.cを利用しようと思っていま す。 > 実際、guard は verbatim に転写できていません。参考実装が define-syntax > を使っている関係から中途半端に C に手が出ているために、解釈が紛れ込ん > でいます (「何の」かは難しいところですが)。その証拠に expand-macro を > 使えば sigscheme の実装と SRFI-34 の参考実装を scheme level で見分けら > れます。 > > (define-syntax macro > (syntax-rules () > ((_) (let ((sym 0)) sym)))) > > ;; srfi-34 の実装をコピペ (省略) > > (write > (guard (err (else #f)) > (expand-macro macro))) 想定している「解釈」「機械的に移植」の範囲が食い違っているからと は思いますが、これをもって移植失敗の実例とするのはさすがに勘弁し て欲しいです。 あれを実装した時点では「quoteしたオブジェクトをevalしたら元のオ ブジェクトが得られる」という前提が崩れる事は想定してなかったわけ で、実際scm_s_quote()だけを元の実装に戻せば上記の2実装は同じ結果 を返します。「参照実装がquoteの実装に依存しないのだから、その移 植版でもかくあれ」というレベルのverbatimなマッピングを目標にして いるわけではありません。 ------------------------------- ヤマケン yamak****@bp*****
