Re: arithmetic issues William D Clinger (18 Jan 2006 23:27 UTC)
Re: arithmetic issues Alan Watson (19 Jan 2006 01:13 UTC)

Re: arithmetic issues William D Clinger 18 Jan 2006 23:27 UTC

Dr Alan Watson wrote:
> No. I am suggesting that you to reconsider your earlier statement that
> "most hardware now supports them [flonums] much more efficiently than
> they could be implemented in a library module".

Please consider it reconsidered.

> But, anyway, I don't think this likely to be a useful discussion.
> Flonums should be available in Scheme on these platforms. The question
> is whether flonums should be in the base language or pushed off into a
> library. I would say that flonums are not *needed* in the base language
> and so should be pushed off into the library.

I would agree with that, if we had a suitable mechanism
for such libraries.  SRFI-77 was written before SRFI-83,
and it isn't clear to me whether SRFI-83 libraries are
even adequate for this.  SRFI-83 makes no provision for
libraries written in languages other than R6RS Scheme,
and SRFI-83 explicitly does not require implementations
to evaluate library forms interactively, nor does it make
any provision for interaction between libraries and the
load procedure.  Indeed, there does not seem to be any
portable way for a Scheme programmer to refer to a SRFI-83
library except from within some other library.

I am hopeful that this situation will change, but I do not
want SRFI-77 to depend upon changes that have not yet been
made to SRFI-83.

> Would the following proposal satisfy your goals:
>
> (a) Mandate unlimited size exact integers in the base language.
>
> (b) Push fl+ et al. off into a library module.

No.  The fundamental problem with R5RS arithmetic is that
programmers cannot rely on the behavior of the arithmetic
primitives.  Mandating exact integers of unlimited size
would help, but programmers would still not know whether
(/ 3 4) will evaluate to 3/4, 0, 1, or 0.75.

To solve this problem, we have to require some subset of
the tower that has reasonable closure properties, while
banishing any arithmetic operations that are not closed
over that subset.  We have to do both.

In my opinion, two fairly extreme positions are the most
attractive.  Either require the full tower as part of the
base language, or require only the fixnum/flonum foundation
while banishing + and the other generic operations to the
libraries.

Will