[R6RS] shift operators

[William D Clinger]

Kent wrote:
> An implementation is not required to raise an exception
> in unsafe mode.

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

> 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).

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

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

The problem, once again, is that the fixnum prefix has
the nice mathematical property, and is more efficient,
while the fx prefix does not have nice closure properties
and does more run-time checking.  Checking that the result
is a fixnum cannot be done until the computation has been
completed.  One solution is to require fx+ and friends to
signal an error if any intermediate result is not a fixnum,
but that requires us to be more specific about intermediate
results.  I'd prefer to restrict the procedure to just two
arguments than get into a discussion of its intermediate
results.

Will