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.
Taylor Campbell wrote:
Coercion to integers of a given modulus, for example, from other integers, is accomplished with a procedure we already have in R5RS, namely MODULO;
Not the same. The coercion creates a value with a different run-time type, such that the generic + operator uses modulo arithmetic.
Neither: it's not the operations that change: It's the operand that changes. The operation + is already defined so that if the operands are IEEE 64-bit *values* then we use 64-bit flonum flonum addition etc. But's that's the way R5RS already works - we're just being more precise and allowing for more data types. Why would it not be perfectly allowable for, say, the * procedure to return a 128-bit flonum when given two 64-bit flonums?
Does that make any sense? A more meaningful example would be multiplying to 64-bit fixnum (modulo-64) integers to yield a 128-bit result.
Similarly, why would you not specify that you want IEEE 64-bit flonum arithmetic using an explicit IEEE 64-bit flonum operation, like IEEE-FLO64*, to clearly indicate this in the program?
First, its more verbose. But more importantly, if you change the representation of a variable then you have to check and possibly change every place in the program that references the variable. I.e. it's more error-prone, hurts modularity, and hurts maintainance.
The declarations coerce to an appropriate data type. I.e. you coerce an integer to a (modulo-int N), and arithmetic on the (modulo-int N) *type* is defined to be modular. So are you saying that the 'type declaration' really *does* affect the semantics of the operations on the integer objects? I'm not quite clear on how you can otherwise signify that some integer is 'modular' in a way that the + operator can distinguish by run-time tag; integers are integers.
Conceptually, there *is* a separate run-time tag. We have an extensible type system with records, so we're not limited to a finite set of tags. I.e. a modulo-N value can be converted to/from integers, but it is not a (regular-old) integer. Now the compiler as an optimization can and should "unbox" the values and generate machine arithmetic without tags. Note I'm not saying my proposal is the "right" approach nor am I pushing it for R6RS. However, I think it is consistent, and has a number of advantages: it is (at least partly) implemented, is fairly readable and compact, generates good code using simple type-propagation, and is useful for documentation and catching errors. -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/