This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
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