fixnumXXX and fxXXX names, and other things

[Marc Feeley <feeley@xxxxxxxxxxxxxxxx>]

SRFI 77 specifies two classes of operations on fixnums: operations  
which perform modulo arithmetic (with fixnumXXX names), and those  
which signal an error on overflow (with fxXXX names).  This naming  
convention is obscure because nothing in the name helps distinguish  
the two classes of operations.  Why not be explicit and say

    (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 in

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

Marc