On 18-Jun-06, at 1:47 PM, William D Clinger wrote:

> Concerning duplicate names for operations such as fixnum< and fx<,
> Marc Feeley wrote:
>> What is the rationale for all this duplication?
>
> See the second rationale in the Fixnums section.

The rationale for the two sets of names is wrong.  Adding redundant
procedures adds confusion.  For the trivial reason of avoiding bias
toward either set of names the SRFI introduces 30 redundant
bindings.  These bindings have a cost in additional global variables,
and in a system with precise error messages you actually need
different procedures for the fixnumXXX and fxXXX procedures so that
the error messages can indicate the name of the procedure that
appears in the user program.  Also, as I said in my previous message,
the prefixes "fixnum" and "fx" give no clue to the nature of these
operations (to me "fixnum" and "fx" are synonyms, better prefixes
would be "fxring" and "fx"), so it is hard for the programmer to
determine which one is the correct one to use.

>> The main motivation for fixnum specific operations is that
>> they are much faster than generic arithmetic.
>
> That is one motivation, and for some people it may be the
> main motivation, but it is not everyone's main motivation.

I didn't make this up.  It is the only rationale for fixnums in the
SRFI 77 rationale:

   Fixnum/flonum arithmetic is already supported by many systems,
mainly for efficiency.
   Standardization of fixnum/flonum arithmetic would increase the
portability of code that uses
   it, but we cannot standardize the precision of fixnum/flonum
arithmetic without making it
   inefficient on some systems, which would defeat its purpose.

Is there another rationale for fixnums?

By using a multiple values API for some fixnum operations, you are
limiting the practical portability of those operations.  This is
inconsistent with the rationale.  I repeat: in which implementations
of Scheme will the multiple values API be faster than the equivalent
pair of operations which return single values?  I believe that
efficient implementations of multiple values based on Ashley and
Dybvig's method ("An Efficient Implementation of Multiple Values in
Scheme" paper) will not gain with the MV API because they need to
return the multiple values using a function call, and the overhead of
the function call will drown the few machine cycles saved by the
combined operation.  The choice of a MV API for these operations is
poor engineering.

>> But in many implementations of Scheme multiple values are
>> rather slow...
>
> Presumably the operations that return multiple values will
> be slow in those implementations.  Those who regard efficiency
> as the main motivation for those operations might want to
> avoid implementations in which multiple values are slow.

This view contradicts the rationale.

>> 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?
>
> Inasmuch as most current implementations have not yet gotten
> around to implementing all of the R5RS procedures efficiently,
> it would surprise me if they were to implement all of the R6RS
> procedures efficiently.

My point is that this high barrier to entry will result in poor
portability in practice.  The prospects for portable and efficient
arithmetic in Scheme would be greatly enhanced if the set of
procedures to implement efficiently was small, because more
implementations of Scheme would be willing to put the effort required
to implement them.  I have strong reservations about SRFI 77's
"everything but the kitchen sink" approach.  As an implementer, let
me say that after all the effort put into the Gambit-C numerical
library (roughly 8000 lines of Scheme code, with several fancy
algorithms for bignum operations, representing months of work) I find
SRFI 77's complexity to be a real turn-off when I consider the
changes required to implement it properly.  Surely I'm not the only
implementer to feel this way.

>
>> Can we expect a portable and reasonably efficient implementation
>> of this SRFI to be written as the reference implementation?
>
> Yes.  I'm working on it.
>
> A relatively small subset of the fixnum and flonum procedures
> will be identified as the basic primitives.  If implementors
> implement those primitives efficiently, they will be rewarded
> with a reasonably efficient implementation of the full SRFI.

Can you quantify what you mean by "reasonably efficient" for the
fixnum operations?  Do you mean as fast as the equivalent operation
in C?  Or maybe 2 times slower (which would still be reasonably
efficient in my opinion)?  I fear that unless the fixnum operations
are inlined, the procedure call to the definition in the reference
implementation will slow down the operation by a factor of 10 or
more, rendering it useless in practice for writing efficient code.

Marc