Issue ERROR-CHECKING-IN-NUMBERS-CHAPTER, v1

[Kim A. Barrett <IIM@ECLA.USC.EDU>]

Good work Kent.  A few comments now, with more to follow once I have time to
really look at this.  One thing I'm working on is a function by function
comparison of your list with what we (IIM) currently do.

Many (perhaps almost all) of these could potentially signal STORAGE-CONDITION.
However, as a general rule I don't think we should document that possibility.

ASH: I can't think of any reason for ASH to signal an ARITHMETIC-ERROR.

DECF: might signal SYNTAX-ERROR?  Perhaps this should be PROGRAM-ERROR?

GCD: I can't think of any reason for GCD to signal an ARITHMETIC-ERROR.

INCF: might signal SYNTAX-ERROR?  Perhaps this should be PROGRAM-ERROR?

LCM: I can't think of any reason for LCM to signal an ARITHMETIC-ERROR.

MOD: the second argument is required, so drop the "is supplied and" from the
DIVISION-BY-ZERO case.

REM: the second argument is required, so drop the "is supplied and" from the
DIVISION-BY-ZERO case.

SCALE-FLOAT: might signal ARITHMETIC-ERROR (fp over/underflow).


The possibility of ARITHMETIC-ERROR being signaled in the following functions
may depend on what kind of error should be associated with operations on fp
NaN's, infinities, and such.

  MAX, MIN, SQRT, /=, <, <=, =, >, >=, RATIONAL, RATIONALIZE

Because of CONTAGION-ON-NUMERICAL-COMPARISONS:TRANSITIVE, none of MAX, MIN, /=,
<, <=, =, >, and >= will signal fp over/underflow, and reduce to the question
of what ARITHMETIC-ERRORs are signaled by RATIONAL.

kab
-------