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.
Michael Sperber wrote:
Now, the Issues section in the SRFI is pretty long. We were hoping to get some feedback on where people stand on these issues, so it'd be great if you could see it as some kind of questionnaire and just fireoff your position on the issues where you have one.
* 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.
No strong opinion. However, an application shouldn't have to use diffeent arithmetic operators depending on whether they're sticking to the core language, or using the full tower. I.e. I'd like to use + porably either way. Also don't overspecify flonums - an implementation might want to only or by default use arbitrary-precision decimal arithmetic, for example. * Should a minimum precision be required for fixnums or flonums? I think it is reasonable to require 24-bit (or 28-bit?) fixnums. flonums are trickier to specify.* Should the range of a fixnum be restricted to a power of two? To a two's complement range?
Well, I'm somewhat dubious of the concept of fixnum and especially a single fixnum type. Sure, if here is a reason for it. * Should the binary fixnum/flonum operations allow other than two arguments? Probably, just to avoid an confusing special case. * Should R6RS allow other inexact reals beside the flonums? Well, R6RS should allow more that type type of inexact real. An implementation might and one or more precisions of IEEE floating point and perhaps decimal arithmetic.* Should the R5RS procedures for generic arithmetic (e.g. +) remain in R6RS?
Yes: 4. + is defined as in R5RS.* Given that this SRFI suggests requiring all implementations to support the general complex numbers, should abs (and exabs and inabs) be removed?
Don't remove abs - it's shorter and beter-known than magnitude.* 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?
That seems worthwhile.* 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?
Yes, for the latter: http://www2.hursley.ibm.com/decimal/ * Should `(floor +inf.0)' return +inf.0 or signal an error instead? 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.
Agree - get rid of it. (Ditto for "syntax" vs "library syntax".) -- --Per Bothner per@xxxxxxxxxxx http://per.bothner.com/