[R6RS] Draft of arithmetic SRFI

[Michael Sperber]

William D Clinger <will at ccs.neu.edu> writes:

> 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.

I actually don't think that's true.  At least the reference
implementation takes great care never to wrap.  One place where it
really hurts is with generic arithmetic: When adding two fixnums, I
basically have to always convert to bignums and then coerce back if I
don't have an overflow signal---that's expensive.

> 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,

SRFI 34 is probably unsuitable for this---it was certainly designed
explicitly without that in mind.  I suspect most Scheme
implementations use a different mechanism than the regular
exception-handling facility for hooking into overflow, such as a
global trap table or something.

Note that overflow could be signalled by mechanisms other than
exception handling.  There might just be an additional argument to the
FX... procedures:

(fx+ 1 2 (lambda (a b) <overflow handler>))

The advantage with the model we have now is that the API issues are
pretty clear, and that it's straightforward to use.  So my suggestion
is to have the community say something about this until we consider
changing what we have---I'm confident that will actually happen.

-- 
Cheers =8-} Mike
Friede, V?lkerverst?ndigung und ?berhaupt blabla