[R6RS] shift operators

[dyb at cs.indiana.edu]

> As you know, I'm more concerned about the efficiency of
> safe mode.

I'm equally concerned about both.  Even if I were concerned only with safe
mode efficiency, however, I'd want the unsafe-mode operators to be
efficient targets for a translation pass that replaces safe-mode operators
with unsafe-mode equivalents whenever it can deduce that the input and
output values are going to be suitable.

> > I think a goal for the fx operators should be to allow
> > a Scheme implementation to generate unsafe-mode code
> > roughly as efficient as a C compiler can produce for C
> > counterparts.
>
> I thought the fixnum prefix was supposed to indicate the
> mathematically well-behaved and more efficient version,
> while the fx prefix was supposed to indicate the slower
> version that performs more run-time checking, has less
> pleasant closure properties, and returns the same result
> in all implementations (if it returns a result at all,
> which is the reason for the additional checking).

That's all fine, but my take is a bit different: the fx operators should
behave like the corresponding arbitrary-precision versions within the
fixnum range, with full error checking in safe mode and (possibly) native
(near single-instruction) efficiency in unsafe mode.  The idea is that
code that uses them can be tested in safe mode and put into production in
unsafe mode.  The fx operators may be slower than the fixnum operators in
safe mode but should not need to be slower in unsafe mode.

In any case, my comments about the fx operators apply equally to both sets
of operators, i.e., the extra test and branch is there in the unsafe
fixnum as well as the unsafe fx operators.

> > Furthermore, negative shift counts are not as intuitive
> > as separate operators.
>
> That's a more compelling reason IMO, but doing away with
> negative shift counts would create an incompatibility with
> SRFI 60.  If we're going to create that incompatibility,
> then we ought to consider changing the order of arguments
> on some of the other operations as well.  See the issues
> list.

Diverging from SRFI 60 doesn't seem like a big deal, especially in this
case where it is trivial to define the +/- shift-count operators in terms
of the pairs of separate operators.

> > To which operators are you referring?
>
> fx+ and several other operations require precision
> proportional to the number of arguments.  See the issues
> list and the examples for those operations.

Ah, I see.  I agree with you that fx+ (and others as appropriate) should
be restricted to two arguments.

Kent