Thomas Bushnell BSG <xxxxxx@becket.net> writes:

>> Why not the other way around: that the default behavior is known,
>> and implementations may provide other fancy choices which must be
>> turned on explicitly?
>
> Nope.  We should maintain consistency over time in the meanings of the
> functions.  It is not a decent idea to have the next RnRS standard
> specify addition in a way which is fundamentally incompatible with its
> predecessors.

It's compatible with existing practice.

> What you are describing as "fancy choices" are, in fact, the way
> Scheme has always behaved.

Any existing implementation uses any other representation by default
than fixnums/bignums, ratnums, flonums, and pairs of real numbers
which represent complex numbers?

(The difference between fixnums and bignums should not be exposed
except perhaps by some weird functions used as an efficiency hack.
Other representations are important though.)

Besides the fact that they don't all support the whole set, other
differences are minor. They differ in the behavior on overflow,
in the textual syntax of special values, in exactness of components
of complex numbers, in the ability to compute some mostly-inexact
functions for certain arguments exactly, and in the correctness
in maintaining every bit of precision by certain operations (like
converting a ratnum to a flonum, or converting a flonum to a string).
These are differences which could be reduced by a future standard.

CLISP supports variable-precision floats under the name of long
floats, apart from fixed-size IEEE and non-IEEE floats. This is fine
by me: sometimes very useful, not imposed on the user by default, and
doesn't have to be provided by every implementation because it's too
painful to implement. Well, from the user's point of view it would be
great if it was standarized and provided by every implementation, but
this choice is not realistic for now.

I'm pretty sure that there exist some Lisp or Scheme packages which
implement numbers with lazy streams of digits, decimal fractions and
arithmetic in Z/n. It's fine, as long as they don't take over the
common defaults.

--
   __("<         Marcin Kowalczyk
   \__/       xxxxxx@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/