YamaKen
yamak****@bp*****
2005年 11月 6日 (日) 23:11:28 JST
ヤマケンです。 At Thu, 3 Nov 2005 22:08:09 +0900, mover****@hct***** wrote: > > 了解です。ではstorage-continuation.c, storage-symbol.c, storage-gc.cの順に > > 分離作業を行います。そして最後にdatas.cをrenameと。 > 分離作業終了しました。 > port回りも、port-mbc.c等の様にすると全体の見通しが良くなるかもしれませんね。 言われそうな気がしてました。でも正直迷ってるんでしばらく現状のま まで考えさせてください。 こっちはクラス名とファイル名が対応してるんで正直今のままにしとき たい気持もあるし、将来的にSigScheme非依存コードとしてlibuim等に 簡単に流用もできるようにしておきたいので、ファイル名そのままでディ レクトリを分けた方がいいかもしれないと考えてます。 それからちょっと話が外れますが、関数テーブルのファイル構成につい て。sigschemefunctable.cを自動生成するようになって手間とコードサ イズがだいぶ減らせるようになりましたが、もし余力があれば以下の点 にも対応してもらえると嬉しいです。 ・SCM_USE_DEEP_CADRSとSCM_USE_NONSTD_FEATURESの関数群を別テーブ ルに。これはファイル分割するのが手っ取り早いですかね。 ・1つのファイルに集約しないで元になったファイルに1対1で対応する ファイルを生成。SRFI等のoptionalなコードは将来的に動的ロードす る事も考えられるので、関数テーブルもそれぞれのモジュール毎にファ イル分割されるのが望ましい。 ・Cの関数名の復元。先程commitしたscm_decl.rbを使えばSchemeの procedure名と無関係に関数名を付けられるので、ScmOp_sscm_*()の sscm_プリフィクスとかは無かった事にしてsiod_eqlも元に戻しましょ う。 それとlet*に対応するCの関数はletrecと合わせてletstarにしようと 言いましたが、string=?がstringequalpなのはさすがに読みにくい気 がするんで、そういうのはstring_equalpみたいに区切ってもいい事 にしませんか? 引っ掛き回してしまって申し訳ないですが。 私の方はSRFI-34まわり(仕様に沿ってない部分の修正とcontinuation の内部実装への直接アクセスの隠蔽)を進めようかと思ってますが、太 田さんの方でやりたければ別の作業に移りますんで遠慮なく言ってくだ さい。 できれば年内にtrunkにSigSchemeをマージしたいんで、各人のやりたい /得意な分野でどんどんTODOを潰していくのがいいんじゃないかと思い ます。 ------------------------------- ヤマケン yamak****@bp*****