R6RS:翻訳:R6RS:5.4 Argument checking

R6RS:翻訳:R6RS:5.4 Argument checking

5.4 引き数の確認

本報告書や標準ライブラリの一部で定められている手続きの多くは、受け付ける引き数に制約がある。典型的には、ある手続きは特定個数の、特定の型の引き数だけを受け取る。構文フォームの多くも同様にその下位フォームのひとつ以上が評価される値を制限している。これらの制約は、プログラマと実装系の両方の責任を暗示している。特にプログラマは、値が実際に仕様で述べられている制約に従っていることを保証しなければならない。実装系は、妥当な範囲、可能な範囲、特定の操作が成功裏に完了する必要があることを認める範囲で、仕様にある制約が満たされているかどうかを確認しなければならない。実装系の責任については R6RS:翻訳:R6RS:6 Entry format や本報告書を通してより詳細に述べられている。

実装系にとって、仕様にある制約を前以って完全に確認することが常に可能であるわけではないことに注意しなければならない。例えば、ある操作が特定の性質をもった手続きを受け付けると指定されていた場合、一般にこのような性質を確認することは不可能である。同様に、リストとその操作から呼び出される手続きを受け付ける操作もある。リストは (rnrs mutable-pairs (6)) ライブラリ(R6RS:翻訳:Standard Libraries:17 Mutable pairs 参照)を使って変更することができるため、操作の開始した時点でリストであった引き数が、操作の実行中にリストでなくなることもある。また、手続きは別の継続を使って脱出することもあるかもしれず、その操作についてより多くの検査をすることが妨げられている。そのような手続きの呼び出しそれぞれについて、その操作に引き数がリストであることを確認することを要求するのは現実的ではないであろう。さらに、リストを受け付ける操作にはその機能を実行するのに、リストの一部分だけを走査する必要があるだけのものもある。実装系に対して、規定された制約が満たされていることを検証するために、リストの残りの部分を走査するように要求すると、性能上の妥当な想定をやぶることになるかもしれない。これらの理由から、プログラマの義務が実装系の確認義務を越えることもあるのである。

実装系が引き数への制約の違反を見つけた場合、 R6RS:翻訳:R6RS:5.6 Safety で述べられている実行の安全性と一貫性のある方法で、 &assertion 型の例外を発生させなければならない。

More ...