何をしようかな
ヤマケンさんが色々やったはる。mand_max.diff については見た瞬間バカみたいな気分になりましたね(顔。超単純に解決されちゃったよ。
太田さんも帰ってきたし、しばらくは commit が続きそうだ。そこで私は何をしようかな。
- 環境 frame の簡略化とか
- SIOD_BUGS な関数に lint コード入れるとか
- 数年前に書いた文字コード処理を持ってきて encoding.c を充実させるとか
- port の改造 (string port 追加など) とか
- SCM_SHIFT_ARGS interface 改定とか
- list_ctor (要相談) とか
- define-macro (syntax-rules は保留) とか
結構あるな。とりあえず FUNCTYPE の流れから、ARGS interface ですかね。他のも一応心積もりはあります。
そんなわけで放置状態になってたSHIFT マクロ再編への要望についてコメント。
のっけから主観的でアレなんですが、名前は SHIFT より POP の方がいいと思います。Scheme というか LISP ではリストを stack として使うのは常套手段ですし、Schemer にはそっちのがいいんでは。Gauche でもこの操作は pop! として用意されています。まぁどっちでもいいっちゃいいんですが。
'shift'はスクリプト系言語のそれの動作イメージを借用してるのでshiftした時点で値が左辺に渡ってしまうのが基本で、その後にevalするように読める名前は違和感があります
いや、shift のち eval でいいですよ。Perl の shift でも、shift (@ary) は先頭を破壊的に取り出して継続に渡すだけであって、代入は含みません。本当なら EVAL (SHIFT (args), env) としたいんですが、型チェックなどを含めるのが困難だったので SHIFT_AND_EVAL にしたんです。 それで、SHIFT_THEN_EVAL とかどうだろう、とか思ってたんですが、FUNCTYPE 改造しながら考えてみると、SHIFT_EVAL を使うのは構文だけ→構文はどうせ EVAL するのしないのの algorithm が特殊→SHIFT_RAW 相当のものだけでいいのでは? どう思われますか。これをやめると誓ったんでした。とっととコード書きます。
- できるだけマクロではなく関数に
これなら error message の "
-- TRY_SHIFT_ARG_FOR_INT → TRY_SHIFT_INT_ARG
これは、没にします (TRY_ じゃなくて _FOR_INT の部分)。理由は…あれ、何だっけ。FUNCTYPE 改造時に「これじゃダメ過ぎ」って思ったんですが…
思い出したらまた書きます(顔
