[R6RS] Draft of arithmetic SRFI

dyb at cs.indiana.edu dyb
Wed Aug 3 13:17:39 EDT 2005

> > As I mentioned in Boston, I would prefer that these (and other arithmetic
> > procedures, where applicable) signal an error (raise an exception)
> > whenever the "normal" (non wrapping) arithmetic result cannot be
> > represented as a fixnum.
> Presumably this applies only to safe mode.


> One of the main rationales for the fixnum primitives is as a basis
> for implementing the full numeric tower.  When implementing bignums,
> I think it's easier to deal with arithmetic modulo hi-lo+1 than to
> have to guard against overflow exceptions.

Certainly that's one rationale, but we don't expect everyday users to
use the fixnum primitives to implement the tower.  In practice, I expect
most users to employ fixnums for more efficient limited-range "normal"
arithmetic, and they'll appreciate knowing when their programs exceed
the range.

If it is indeed important to be able to use fixnum primitives as an basis
for implementing the full numeric tower, then we should have two flavors,
like fx+ and fxns+ for signaling and non-signaling fx+.


More information about the R6RS mailing list