Unspecifiedの数とarity

scheme nmosh

成立しないifはunspecifiedになるとR7RS等に記述が有る。よく、unspecifiedを生成するイディオムとして

(if #f #f)

を使うけど、ゼロ値を使わないのは何故だろうか:

(values)

ただ、確かに、

(call-with-values
  (lambda () (if #f #f))
  (lambda e (display (length e))))

のようなコードでunspecifiedの数を数えると、大体1になっている。確か、R6RSでは未定義個数の未定義値を返すことが出来た部分でも、R7RSでは1つの未定義値となっていた気がするので、未定義の数は1つというのが一応処理系としてのコンセンサスなのかもしれない。
でも、ゼロ値を未定義値にする方が、なんとなく美しいというか、特殊なオブジェクトを用意して未定義値を表現する(= それ未定義じゃないじゃん)よりは良い気もする。SchemeはCLと比べてarityに厳しいので、未定義値が帰る時の挙動が安定していないと不便なケースも有るんだろう。。あと、Chibi schemeのように多値に愛が無い処理系も有る。

Chibi schemeの多値は単に多値オブジェクトで、call-with-values等で明示的に受け取らないと悲しいことになる。もっともChibi schemeのような実装にも、多値の長さに制限がないというメリットがある。nmoshは多値の長さ(= 事実上手続き引数の個数制限)が100程度に制限されている。現状のSchemeではこの制限をクエリする良い方法が無い。
引数個数制限はご無体な気もするが、Cの呼び出し規約のように関数呼び出しをスタック経由で行う規約は基本的にヒープサイズ制限よりもスタック長制限が先に来る。常識的に考えて固定arityの引数が100を越えることは無いので、可変arityの手続きの呼び出し規約をスタック渡しとオブジェクト渡しに分けるのは効果的かもしれない。