On Fri, 20 Jan 2006, William D Clinger wrote:

> Secondly, the standardization of the fixnum/flonum base
> will improve the portability of programs that, for whatever
> reason, already use implementation-specific fixnum or flonum
> operations.

Erf....  Aesthetics aside, yes, it *is* correct, if you're
going to have these modular-ring fx-foo and limited-precision
fl-foo operations, to make them different from general numeric
operations.  This is because they are different operations
from the general numeric operations, and in some circumstances
give different answers.

A type declaration form, like this:

   (the fixnum (+ (the fixnum x) (the fixnum y)))

Has the advantage of not changing the semantics of the code
at all in the case that the type declarations are correct
and keeping the type stuff simple and separate from the
code, which I like; if the type declarations are not
correct (for example, if the result is not a fixnum)
the expression is simply an error.

The disadvantage is that the semantics of an error are
unspecified.  Various implementations could return the
modular answer for a representation in ones-complement
or signed-magnitude instead of twos-complement, or return
an error value, call an error continuation, or invoke
nasal demons, and if there are things you want to do
that *RELY* on a particular roundoff/rollover behavior,
you'd like to specify the semantics of the case that
with plain-vanilla addition would be an error.

This SRFI suggests fx+ as an operation that performs a
modular addition instead of actual addition, thereby
giving an addition-like operation that is closed over
a limited subrange of numbers and has predictable
behavior in boundary cases.  But its semantics are not
the semantics of addition, and it would be wrong to
use the unadorned '+' symbol, regardless of declarations
on its operands or results, to refer to it; the operation
that '+' refers to is addition, which is not closed on
any subrange of the real numbers except the trivial
subrange consisting of zero.

So, yeah, I get it.  If you want to rely on a *particular*
roundoff or rollover behavior on a fixed-width representation,
then you need specialized operations that have well-defined
semantics in cases that are simply errors in a system with
non-modular addition and optional type declarations.

BUT....  I never, ever, want to write code that relies on
a *particular* roundoff or rollover behavior, except for
actually *implementing* the numeric tower with bignums and
an orthogonal set of exact and inexact numbers, and once it
exists, I want all those modular and fixed-size-rounding
operations swept under a rug where I never ever have to
look at 'em or think about 'em or have 'em polluting my
namespace again.

The reference implementation that this SRFI provides takes
care of that need with code that implementors who have not
implemented the full tower can just drop in -- leaving
programmers access to the full numeric tower and giving
them no particular motivation - aside from speed dinking at
risk to program correctness - to use these operations for
anything else.

So I think that what we have here is motivated by one
problem -- implementations that don't provide the full
numeric tower -- proposes a minimum ground on which to
solve it, and provides the solution given that minimum
ground.  There is no reason once the solution is in
place to leave that ground exposed.

				Bear