This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
(fxring+ x y) for the version which implement arithmetic on a quotient ring of the integers,
and(fx+ x y) for the version which returns the same result as (+ x y) as long as x, y and x+y are fixnums.
There is a high degree of duplication of functionality among the fixnum operations. Take for example,
(fixnum= X Y Z) which is identical to (fx= X Y Z) There is also duplication infx<, fx>, fx<=, fx>=, fxzero?, fxpositive?, fxnegative?, fxodd?, fxeven?, fxmax, fxmin, fxnot, fxif, and so on...
What is the rationale for all this duplication? Is there some subtle difference in semantics I'm missing? When should the fixnumXXX version be preferred over the fxXXX version?
There are relatively few fixnum operations where it makes sense to have a version which implements arithmetic on a quotient ring of the integers (mainly +, -, *, quotient, modulo, remainder). So I expect few fxringXXX procedures and many fxXXX procedures.
I find it odd that some fixnum operations return multiple values (fxdiv+mod, fixnum+/carry, fixnum*/carry, ...). The main motivation for fixnum specific operations is that they are much faster than generic arithmetic. But in many implementations of Scheme multiple values are rather slow because the values are packaged up in a vector that is allocated on the heap, this vector must then be accessed to get to the values. Moreover the main use of the XXX/carry operations is to implement bignum arithmetic, but this will not be practical if these operations are slow. I'm sure if you take the time to benchmark this on some of the main implementations of Scheme you will see that it is considerably faster to perform two independent operations (for example use calls to fxdiv and fxmod instead of a call to fxdiv-mod). Have you analyzed performance on current Scheme systems, and if so, on which implementations of Scheme is the multiple values API faster and by how much?
Finally, I haven't counted the number of procedures defined in this SRFI, but it is clearly very high. Do you realistically think that current implementations of Scheme will be updated to implement all these procedures efficiently? If for expediency implementors decide to use the portable implementation, I'm afraid that "portability" of arithmetic code will only have a theoretical meaning. Can we expect a portable and reasonably efficient implementation of this SRFI to be written as the reference implementation? That would greatly help its acceptance.