[R6RS] shift operators

[dyb at cs.indiana.edu]

> Concerning the shift operations, Kent wrote:
> > Furthermore, handling negative arguments will require an extra test
> > and branch on most machines, and for the fixnum operators, handling
> > count arguments greater than the number of bits in a fixnum will
> > require an additional test and branch.
>
> Treating a negative argument as a shift in the opposite
> direction doesn't require more tests than raising an
> exception when the argument is negative, which is what
> Kent wants.  Similarly for dealing with count arguments
> that are greater than the number of bits in a fixnum.

An implementation is not required to raise an exception in unsafe mode. 
With separate left- and right-shift operators and nonnegative shift
counts, an unsafe-mode shift can be done without any tests or branches
on most machines.

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.  Separate left- and right-shift
operators with nonnegative shift counts meet this goal, while shift
operators with both negative and nonnegative shift counts do not.

Furthermore, negative shift counts are not as intuitive as separate
operators.  I've seen compiler students become confused trying to use Chez
Scheme's ash operator (borrowed from Common Lisp), which uses negative
shift counts to implement right shifts, and I have since given them
shift-left and shift-right operators to avoid this problem.

> It turns out that some of the fx operations cannot be
> implemented using fixed precision arithmetic.  If this
> is inconsistent with the editors' intentions, then we
> should take another look at the revised spec for the fixnum
> operations anyway, and we can discuss the shift operations
> along with the fx operations.

To which operators are you referring?  If an operator really requires
arbitrary (non-fixed) precision, then we should reconsider it.  If it just
requires an extra bit or two or even an extra word, it's probably okay.

Kent