Formal comment #166 (enhancement) Make unspecified return values of eq? / eqv? unspecified Reported by: Mike Sperber Version: 5.92 Summary The specification of eq? and eqv? should allow portability-checking implementations. Description In the current draft, the return value of eq?' and eqv?' isn't specified for all combinations of arguments. Yet, the return value is constrained to be #t or #f. This makes it easy to write unportable programs, for example by using `eq?' to compare characters under the assumption that it's faster than `char=?', or by using it to a number to assumed to be a fixnum with an immediate representation that `eq?' handles. As an implementation must return #t or #f even when applied to arguments where the return is unspecified, the draft does not permit an implementation that would detect (some) unspecified cases and notify the programmer and/or user in that case. Suggestion Allow implementations to return other values than #t or #f for the unspecified cases, and also allow them to abort the program or raise an exception for those cases. RESPONSE: Despite being left open to interpretation, eqv? is not entirely unspecified for any pair of objects, since it returns true if the two objects "should normally be regarded as the same object". Thus it may be useful even in cases where different implementations may return different boolean values, e.g., for applications such as memoization. Allowing eqv? to abort or raise an exception would require additional checks or setting of exception handlers in such applications. Allowing return of an unspecified value does not seem useful since eqv? is typically used only for its truth value and even unspecified values have truth values. The situation is similar for eq?. Therefore, the formal comment's suggestion will not be adopted.