There is much I disagree with in this proposal, but I thank the SRFI authors for their excellent work in framing these issues and writing up a straw-man solution. * Instead of requiring the full numeric tower, R6RS could require only the fixnum/flonum base, and make the full tower available as modules in the standard library. Exact integers (fixnums and bignums in the core). Flonums and the rest of the tower in the library. If you have a small implementation and don't want to implement full bignums, then implement fixnums, check for overflow, and signal an error on overflow. Under no circumstances specify modular arithmetic as the behaviour of the standard operators on exact numbers. Either they should give the right answer or they signal an error. Basically, I think the solution to the type analyis problem is putting type information into the language and allowing procedures to be declared or inferred to be constant. * The main problem with banishing the full tower to a library is that read, write, and several other procedures must know about the external representations of all numbers. Okay, but there are solutions. For example, define a potential number, like CL, define "string->number" and "number->string" in the core and in the library, and have read and write use the current definitions of these procedures. * Should a minimum precision be required for fixnums or flonums? In an implementation written in C (i.e., without access to the carry flag) running on a 32-bit processor, it might make sense to use 16-bit fixnums to make it easy to check for overflow and the need for bignums. Of course, in a sense, you have access to the carry flag because "long long" is at least 64-bits. However, using long longs to check for overlow may be less efficient. On the other hand, if bignums are part of the core, there is less need to force a decent range for fixnums, provided bignums can be used as indices and sizes. * Should the range of a fixnum be restricted to a power of two? To a two's complement range? If you have bignums, then the range of a fixnum becomes less important. However, I see no problem with restricting it to a two's complement range. * The fixnum operations provide efficient fixnums that "wrap." However, they do not give efficient access to the hardware facilities for carry and overflow. This would be desirable to implement efficient generic arithmetic on fixnums portably. On the other hand, there isn't much experience with formulating a portable interface to these facilities. One of the primary motivations for this disappears if bignums must be part of the core. * Should the binary fixnum/flonum operations allow other than two arguments? Yes. * What are the semantics of "safe mode" and "unsafe mode"? Perhaps leave the semantics of "unsafe mode" to the implementation? * Should R6RS allow other inexact reals beside the flonums? At the very least, it must allow for different types of flonums. * Should the R5RS procedures for generic arithmetic (e.g. +) remain in R6RS? If R6RS does not adopt a R5RS-style model for the generic arithmetic, should it still provide more R5RS-compatible generic arithmetic as a library? Yes. It doesn't matter much to me whether the generic arithmetic is part of the core or the library. * Given that this SRFI suggests requiring all implementations to support the general complex numbers, should abs (and exabs and inabs) be removed? No. * The real?, rational?, and integer? predicates must return false for complex numbers with an imaginary part of inexact zero, as non-realness is now contagious. This causes possibly unexpected behavior: `(zero? 0+0.0i)' returns true despite `(integer? 0+0.0i)' returning false. Possibly, new predicates realistic?, rationalistic?, and integral? should be added to say that a number can be coerced to the specified type (and back) without loss. Okay. If I understand this correctly, real? would be (and (number? z) (exact? (imag-part z)) (zero? (imag-part z))) and realistic? would be just (and (number? z) (zero? (imag-part z)). I am not sure that the new predicates are needed, but would not object to them. Maybe call them realish? rationalish? and integralish? :-) * The fixnum, flonum, and inexact arithmetic come with a full deck of operations, including some that are defined in terms of integers (such as quotient+remainder, gcd and lcm), and others that are easily abused (such as fxabs). Should these be pruned? How can fxabs be abused? * Most Scheme implementations represent an inexact complex number as a pair of two inexact reals, representing the real and imaginary parts of the number, respectively. Should R6RS mandate the presence of such a representation (while allowing additional alternative representations), thus allowing it to more meaningfully discuss semantic issues such as branch cuts? Yes. * The x|53 default for the mantissa width discriminates against implementations that default to unusually good representations, such as IEEE extended precision. Are there any such implementations? Do we expect such implementations in the near future? Others have said yes. I have nothing to add. * Should `(floor +inf.0)' return +inf.0 or signal an error instead? The former. * The bitwise operations operate on exact integers only. Should they live in the section on exact arithmetic? Should they carry ex prefixes? Or should they be extended to work on inexact integers as well? No. No. How/why? * The division between regular procedures and library procedures is somewhat arbitrary. And appears does not appear to constrain implementations in any way. It's just a hint to implementors, yes? Why not just make everything a regular procedure? Regards, Alan -- Dr Alan Watson Centro de Radioastronomía y Astrofísica Universidad Astronómico Nacional de México
