[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: arithmetic issues

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.

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