[R6RS] Draft of arithmetic SRFI

[William D Clinger]

Kent Dybvig wrote:
> 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.

Having exception handlers for those exceptions makes it easier in
theory, but you can't use exception handlers in practice unless
they're fast enough to be practical for the application.  For this
application, and for exception handling mechanisms such as SRFI-34,
it would be much faster to check the result of wrapping operations
than to avoid the check but go through the exception mechanism when
an overflow occurs.

SRFI-34 does not specify an exception handler's continuation.  That
means our portable implementation can't count on the handler's
continuation being the same as the continuation for the call to raise.
That means every arithmetic operation would have to capture a
continuation in case the exception handler needs it.  That would
make our portable implementation impractical, and the practicality
of that portable implementation is key to implementors' acceptance
of this arithmetic SRFI.

Will