Formal comment #52 (simplification)

Exact-Integer and Real (and Complex) are more useful distinctions than Exact and Inexact
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.

From what I have seen, "Using an inexact number where an exact number
is required" is less common of a programming error than producing a
non-real number where a real number is required. This happens when
SQRT, LOG, or EXPT is taken of noisy data without first checking the
range of the argument. If a sample is negative, then a complex number
will be the result of the operation. Calling inexact-only procedures
does not detect this common error.

"Using an inexact number where an exact number is required" also
seems less common than producing a non-integer where an integer
is required. This occurs when / is used instead of QUOTIENT; or
from program logic errors regarding the divisibility of integer
variables. Calling exact-only procedures does not detect this
common error because non-integer exact rationals are exact. 

SRFI-94 introduces 14 real-only and 3 integer-only variants of R5RS
procedures to facilitate numerical type checking and declaration. This
is a significant reduction compared to the scores of procedures
described by sections 16.5 "Exact Arithmetic" and 16.6 "Inexact
Arithmetic".

SRFI-94 being a much smaller burden on implementations, and its not
containing useless functions for orthogonality's sake, I propose that
it be incorporated into section 9.10.2. "Numerical operations"; and
that sections 16.5 "Exact Arithmetic" and 16.6 "Inexact Arithmetic" be
removed.

RESPONSE:

Formal comment #52 asserts that using an inexact number where an exact
number is required is a less common error than producing non-real
numbers where real numbers are required, or non-integers where
integers are required.  All of these errors are known to happen,
but we do not know of any empirical data that would tell us which
kinds of errors are more frequent.

Formal comment #52 also observes that SRFI 94 is simpler than the
(r6rs arithmetic exact) and (r6rs arithmetic inexact) libraries
that are described in sections 16.5 and 16.6 of the draft R6RS.
SRFI 94 addresses a different problem, of course.

Formal comment #52 proposes that SRFI 94 replace the (r6rs arithmetic exact)
and (r6rs arithmetic inexact) libraries that are described in
sections 16.5 and 16.6 of the draft R6RS.

It is not clear why formal comment #52 proposes to replace those two
libraries instead of adding SRFI 94 to them.  The problems
addressed by SRFI 94 are orthogonal to the problems addressed
by the (r6rs arithmetic exact) and (r6rs arithmetic inexact)
libraries.

The arguments for all three libraries are similar, and we have
no evidence that would tell us which of the problems addressed
by the three libraries are more common or important.

The editors have decided to remove the (r6rs arithmetic exact),
(r6rs arithmetic inexact), and (r6rs arithmetic fixnum) libraries
from the report.  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 procedure will be renamed and moved to the
(r6rs base) library.  It will accept only exact integers as
arguments.

The rest of the (r6rs arithmetic exact) library and the
(r6rs arithmetic inexact) library might become SRFIs, in
which case they would have the same status as SRFI 94.