On Sat 29 Jan 2011 01:05, Mark H Weaver <m...@netris.org> writes: > Andy Wingo <wi...@pobox.com> writes: >> I think that certainly when it comes to numbers, strictness is good. In >> particular the r6rs says: >> >> (zero? z) procedure >> (positive? x) procedure >> (negative? x) procedure >> (odd? n) procedure >> (even? n) procedure >> (finite? x) procedure >> (infinite? x) procedure >> (nan? x) procedure >> >> The name of the argument indicates the type, as noted earlier in the >> report. `z' is a complex number, `x' is a real, and `n' is an integer. >> It is an error to pass a non-integer to even?. It is also an error to >> pass a non-real to infinite?. > > Are you reading the final version of R6RS, or a draft? The above > paragraph is not present at: > > http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html
It is hidden here: http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-9.html#node_sec_6.2 For succinctness, the report follows the convention that if a parameter name is also the name of a type, then the corresponding argument must be of the named type. For example, the header line for vector-ref given above dictates that the first argument to vector-ref must be a vector. The following naming conventions imply type restrictions: obj any object z complex number object x real number object y real number object q rational number object n integer object k exact non-negative integer object bool boolean (#f or #t) octet exact integer object in {0, ..., 255} byte exact integer object in { - 128, ..., 127} char character (see section 11.11) pair pair (see section 11.9) vector vector (see section 11.13) string string (see section 11.12) condition condition (see library section on “Conditions”) bytevector bytevector (see library chapter on “Bytevectors”) proc procedure (see section 1.6) Other type restrictions are expressed through parameter-naming conventions that are described in specific chapters. For example, library chapter on “Arithmetic” uses a number of special parameter variables for the various subsets of the numbers. With the listed type restrictions, it is the programmer’s responsibility to ensure that the corresponding argument is of the specified type. It is the implementation’s responsibility to check for that type. > However, I strongly believe that finite?, infinite?, and nan? should be > applicable to non-real complex numbers. They would clearly be useful as > such, otherwise those working with complex numbers will have to > reimplement them. Dunno. Is inf? true if either of the components of a complex number are inf? If that is the case, as you had it, shouldn't finite? be true if either component is finite? Users of complex numbers have to choose what they mean when they ask inf? of a number. I think that's the intention of the report. Andy -- http://wingolog.org/