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 fire
>off 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
xxxxxx@bothner.com   http://per.bothner.com/