Formal comment #40 (defect) Exactness is orthogonal to type Reported by: Aubrey Jaffer Component: arithmetic Version: 5.91 Page 2: 2.1. Numerical Types In order to catch uses of inexact numbers where exact numbers are required, Scheme explicitly distinguishes exact from inexact numbers. This distinction is orthogonal to the dimension of type. To my ear this says that each numerical type must be present in both exact and inexact varieties. If that is the case, then the functions of sections "16.5. Exact arithmetic" and "16.6. Inexact arithmetic" are largely pointless; numeric code must dispatch to any of the numeric types whether restricted to exacts or inexacts. I propose that either * "This distinction is orthogonal to the dimension of type." be removed or modified; or * Sections "16.5. Exact arithmetic" and "16.6. Inexact arithmetic" be removed. RESPONSE: With the draft R6RS, it is true "that each numerical type must be present in both exact and inexact varieties." Integers may be exact or inexact; rationals may be exact or inexact; reals may be exact or inexact; complex numbers may be exact or inexact. From this fact, formal comment #40 somehow concludes that the (r6rs arithmetic exact) and (r6rs arithmetic inexact) libraries are largely pointless. The basis for that suggestion is unclear, but it may be based upon an assumption that the primary motivation for the (r6rs arithmetic exact) and (r6rs arithmetic inexact) libraries is efficiency. Even if that were so, the (r6rs arithmetic exact) library would not be entirely pointless, since it defines bitwise operations whose efficient operation would depend upon access to the underlying representation of large integers. In reality, efficiency has never been a motivation for including those two libraries within the R6RS. It has been observed that most calls to Scheme's arithmetic procedures pass arguments that are either all exact or all inexact; the (r6rs arithmetic exact) and (r6rs arithmetic inexact) libraries provide programmers with a convenient way to assert that this is deliberate, with the safety that may result from raising an exception if the assertion does not hold. As specified in the draft R6RS, however, the (r6rs arithmetic inexact) library is not consistent with the generic operations restricted to inexact arguments because some procedures return an inexact real result (typically a NaN) when the corresponding generic operation would return a more useful inexact complex result. Neither library has been tested in the field. Except for the bit-diddling operations on exact integers, both libraries could be described by a SRFI and provided by portable reference implementations that would be just as efficient as if the libraries were part of the R6RS. The editors have decided to remove both libraries from the report, along with the (r6rs arithmetic fixnum) library. The following procedures will be renamed by changing the "exact-" prefix to "bitwise-", and will be placed within a new (r6rs arithmetic bitwise) library: exact-not exact-and exact-ior exact-xor exact-if exact-bit-count exact-length exact-first-bit-set exact-bit-set? exact-copy-bit exact-bit-field exact-copy-bit-field exact-arithmetic-shift exact-arithmetic-shift-left exact-arithmetic-shift-right exact-rotate-bit-field exact-reverse-bit-field The exact-sqrt procedures will be renamed exact-integer-sqrt and moved to the (r6rs base) library.