Kazuki Ohta
mover****@hct*****
2005年 11月 7日 (月) 01:34:29 JST
おーたです。 > > port回りも、port-mbc.c等の様にすると全体の見通しが良くなるかもしれませんね。 > > 言われそうな気がしてました。でも正直迷ってるんでしばらく現状のま > まで考えさせてください。 > > こっちはクラス名とファイル名が対応してるんで正直今のままにしとき > たい気持もあるし、将来的にSigScheme非依存コードとしてlibuim等に > 簡単に流用もできるようにしておきたいので、ファイル名そのままでディ > レクトリを分けた方がいいかもしれないと考えてます。 ディレクトリ掘るのはちょっと避けたいです。ファイル名とクラス名が別れてしまうのも気持ち 悪いですが、port-*.cの方がソースの構成が分かり易くなるかと。まぁそんなにこだわって 無いので、好きにして頂いて構いません。 > それからちょっと話が外れますが、関数テーブルのファイル構成につい > て。sigschemefunctable.cを自動生成するようになって手間とコードサ > イズがだいぶ減らせるようになりましたが、もし余力があれば以下の点 > にも対応してもらえると嬉しいです。 > > ・SCM_USE_DEEP_CADRSとSCM_USE_NONSTD_FEATURESの関数群を別テーブ > ルに。これはファイル分割するのが手っ取り早いですかね。 やりまっす。僕もこれ気持ち悪いと思ってたので。 > ・1つのファイルに集約しないで元になったファイルに1対1で対応する > ファイルを生成。SRFI等のoptionalなコードは将来的に動的ロードす > る事も考えられるので、関数テーブルもそれぞれのモジュール毎にファ > イル分割されるのが望ましい。 これは現段階ではファイル数が増えて繁雑になると思うので、実際に動的ロードする仕組 みを実装する時に考えます。 ただ、各種プラットフォームで動かす際に動的ロードは鬼門になりそうなので、動的ロードの 実装は考えていません。Symbianに載せる時にuimのpluginの扱いをどうしようかと悩んでる ので^_^; > ・Cの関数名の復元。先程commitしたscm_decl.rbを使えばSchemeの > procedure名と無関係に関数名を付けられるので、ScmOp_sscm_*()の > sscm_プリフィクスとかは無かった事にしてsiod_eqlも元に戻しましょ > う。 見ておきます。 > それとlet*に対応するCの関数はletrecと合わせてletstarにしようと > 言いましたが、string=?がstringequalpなのはさすがに読みにくい気 > がするんで、そういうのはstring_equalpみたいに区切ってもいい事 > にしませんか? 引っ掛き回してしまって申し訳ないですが。 これはそうですね。ちょっと修正方法を考えてみます。 > 私の方はSRFI-34まわり(仕様に沿ってない部分の修正とcontinuation > の内部実装への直接アクセスの隠蔽)を進めようかと思ってますが、太 > 田さんの方でやりたければ別の作業に移りますんで遠慮なく言ってくだ > さい。 どうぞやっちゃって下さい。僕はcompactやってしまいたいんですが、気力がいまいち湧かず... > できれば年内にtrunkにSigSchemeをマージしたいんで、各人のやりたい > /得意な分野でどんどんTODOを潰していくのがいいんじゃないかと思い > ます。 んー、目指せ11月。pending作業って後何がありますかね？ -- ------------------------------------------------- Kazuki Ohta : mover****@hct***** -------------------------------------------------
