YamaKen
yamak****@bp*****
2005年 8月 26日 (金) 15:51:46 JST
ヤマケンです。作業おつかれさまです。 At Fri, 26 Aug 2005 14:33:17 +0900, mover****@hct***** wrote: > > ・consオペレーションとしてのSCM_CONS, CONSマクロの導入 > > - 繁雑な基本操作なので欲しい > > - 現在はSCM_CONSが型チェック付きオブジェクト取り出し用途に使わ > > れているのでそのままでは導入できない。型名をR5RS的にpairに変 > > 更すれば回避できるが、好みに合わないなら型チェック付き取り出 > > しマクロの側を改名する必要がある > 個人的には、pairという型名はいまいちピンと来ません。 実は私もそうなので、合わないなら無理に採用する必要はないと思います。 ただR5RS的にはnil, consといったlegacy namesによる意味的曖昧さを 排除したいという意向が見えるので、それを尊重するのもありかなと思 い提案しました。慣れるだろうし。 ちなみにSRFI-50(Mixing Scheme and C)でも当然ながら SCHEME_PAIR_P()のようにpairという名称を使っています。このSRFIは 他にもAPI名称の参考になる点が多いのでおすすめです。 > 内部で利用するだけなら#define CONS Scm_NewConsとすれば良いのですが、こ > れだと外部から利用する場合に混乱が起きますよね。 内部でもCONSとSCM_CONSが全く別物になるので混乱しますね。 > なので、現状のSCM_CONS > マクロの名前を変更するという事になると思います。custom的にSCM_AS_CONSと > いう名前にしようかと思っているのですが、ピンと来ますかね？ 前の話の流れ上ピンとは来ませんでしたが、本番では大丈夫だと思いま す。 > > ・(cond) ? SCM_TRUE : SCM_FALSE を簡略化するためのSCM_BOOLIZE(仮) > > マクロの導入 > これは反対です。 > SCM_BOOLIZEマクロを導入する事によって、確かに記述は短くなりますが、初めて > ソースコードを見た人にとってはSCM_BOOLIZEマクロの定義を見に行く必要が出て > きます。そうするよりはむしろ上の方が直感的で理解しやすいと思います。 そうですね。やめましょう。デメリットの方が大きいですね。 > 次に行うもの。 > ・SIOD互換のverboseの実装 > ・FuncNameスタイルとfunc_nameスタイルの統一([Anthy-dev 2251]) > ・FUNCTYPEの拡張([Anthy-dev 2238], [Anthy-dev 2241]) > ・datas.cとuim-scm.cの改名([Anthy-dev 2251]) 追加です。 ・SigScheme独自実装のprintをSIOD互換に([Anthy-dev 2415]) ・loadまわりのpathの扱いをSIOD互換に? ([Anthy-dev 2415]) ・スタック保護のGCC 4.0対応([Anthy-dev 2273], [Anthy-dev 2281]) printの方はutil.scmでSIOD互換のsiod-printが提供されてますが、そ もそも"print"という衝突しやすく仕様の不明確な名前の非標準関数は SigSchemeで提供しない方が良いと思います。 なので完全にSIOD互換用途に変えてしまってはどうでしょう。具体的に はdisplayではなくwriteを使う必要があります。 現在のSigScheme独自実装のprintは"displayln"とでも名付けて別途提 供してはどうでしょうか。これなら表示にdisplayが使われる事が明確 にわかります。 > 懸案事項。 > ・tail recursionが起こった場合のback traceをどうするか > 現在はtrace_frameをScmOp_evalの先頭でスタック上に確保しているが、現状末尾 > 再帰が起こった場合にはtrace_frameを作成していない。ただ、mallocを使って確保 > するとオーバーヘッドが大きそう。最初に配列を動的に確保しておく？しかしその場合に > は継続との兼ね合いが微妙になる。難しい。 ------------------------------- ヤマケン yamak****@bp*****
