改善すべき点

何か反応を決め兼ねてる間にちょろっと議論が進んでた。

> 変数命名規則の一貫性欠如

確かにそうなんですが、どうしようもない面も大きいと思います。とりあえず

戻り値を置く場所は ret
string や int など、C オブジェクトを ScmObj にくるんだものを受け取る変数は、そこから抽出した値を置く変数の名前に scm_ を prepend する
リストとしか言いようのないリストは lst、同様に string は str, char は ch…
配列の添字は idx (でも 2 つあるときは?)
リストを traverse するところでは、現在見ているオブジェクトを cur とする

みたいな感じでしょうか? 最後のはやりすぎだと思います。あと、ret のほうも、"ret" だけより目的がわかりやすい変数名がある場合が多いので、一概には言えません。

ヤマケンさんはどういう規則を念頭に置かれてるんでしょうか…それとも「規則」というほど束縛的なつもりではない?

> 引数チェック方法の不統一、さらにチェック自体の欠如

これは問題ですねぇ。チェック自体の欠如は美しさ云々じゃなくてただのバグだと思います。

SCM_SHIFT_* 系のマクロについてですが、私も丁度同じようなものを~~書いていた~~考えてたので渡りに舟です。
;; ×渡りに船→○渡りに舟の間違い? >anthy-6724

でもいくつか不満があって、

型チェックを一緒に隠蔽したい
SHIFT_EVALED という名前は、関数型のときと違って渡すものが EVALED なのか、帰ってくるものが EVALED なのかわかりにくい。
SHIFT_EVALED_5 のようなのを用意するよりは SHIFT_EVALED を繰り返すほうがいいと思う

これらについてはまた明日、考えてる仕組のプロトタイプを書いて載せます。今日は疲れたからもう寝る…

> 第1引数の取り出し手順の不統一

これは一応 (*一応*) 理由があります。ScmOp_equal()/ScmOp_divide() の例で言うと、ScmOp_equal() では、ループに属する処理は for に押し込む形で args = CDR(args) が for に入っていますが、ScmOp_divide() では続きの引数があるかないかで処理を切り分ける必要があるので、それはできません(やれなくもないけどそっちのほうが多分汚い)。
とはいっても、意味もなく順序がちぐはぐな部分が結構あるのは承知していて、引数チェック方法の統一と共に一掃しようと密かに画策していました。言った方がよかったですかね。

> コメント基準の不統一

これは言うか言うまいかと思っていましたが、「コードを見たら一目瞭然な情報」はコメントせず、「前後と密接複雑につながった処理」「コードからは読み取るのが困難な情報」だけに絞ったほうがいいと思います。>kzk さん
;; あとまぁユーモア? beep.cとか読んでて楽しかったし。