arcin 'Qrczak' Kowalczyk wrote:
> These points seem to be contradictory:
>
> > Inexact infinities and NaNs are now assumed to exist. In the
> > previous draft, their existence was not always assumed, yet was
> > sometimes assumed implicitly.
>
> > Although implementations of Scheme are not required to represent
> > infinities and NaNs

I'm going to let the R6RS document editor (Mike Sperber)
figure out how to say it better.  It should be easier to
explain in the larger context of the R6RS.

> Examples for div0 and mod0 lack the 0 subscript.

Thanks for spotting that.

> The whole SRFI is long and has redundant fragments, for example the
> table of atan branch cuts is written 3 times.

Again, I'm going to let the R6RS document editor sort this
out.

Concerning duplicate names for operations such as fixnum< and fx<,
Marc Feeley wrote:
> What is the rationale for all this duplication?

See the second rationale in the Fixnums section.

> The main motivation for fixnum specific operations is that
> they are much faster than generic arithmetic.

That is one motivation, and for some people it may be the
main motivation, but it is not everyone's main motivation.

> But in many implementations of Scheme multiple values are
> rather slow...

Presumably the operations that return multiple values will
be slow in those implementations.  Those who regard efficiency
as the main motivation for those operations might want to
avoid implementations in which multiple values are slow.

> Finally, I haven't counted the number of procedures defined
> in this SRFI, but it is clearly very high.  Do you
> realistically think that current implementations of Scheme
> will be updated to implement all these procedures efficiently?

Inasmuch as most current implementations have not yet gotten
around to implementing all of the R5RS procedures efficiently,
it would surprise me if they were to implement all of the R6RS
procedures efficiently.

> Can we expect a portable and reasonably efficient implementation
> of this SRFI to be written as the reference implementation?

Yes.  I'm working on it.

A relatively small subset of the fixnum and flonum procedures
will be identified as the basic primitives.  If implementors
implement those primitives efficiently, they will be rewarded
with a reasonably efficient implementation of the full SRFI.

The reference implementation won't make multiple values any
faster, but it should provide multiple implementations of the
procedures that would most naturally use them, so systems in
which multiple values are fast can benefit from using them
and systems in which multiple values are slow can eschew them.

Will