[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.

William D Clinger wrote:
I think the major difference between us is what we
mean by the word "adequate".  I want the base language
to be adequate to support a portable implementation of
the full numeric tower.

Would it be correct to say that you want the base language to include all of the tools necessary for building a "full" Scheme? Therefore, since you suspect that R6RS will not mandate the full tower, you want the base language to provide the primitives to implement the full tower.

(I that is the case, I have to say that it I would not have understood that from the SRFI document. Reading it again, the emphasis for the fixnum and flonum routines seems to be on efficiency rather than providing a set of tools for implementing the full tower.)

Okay, that's reasonable and consistent. But where does it end? A "full" Scheme should have some kind of string ports; should the base language expose the reader suffiently to allow these to be implemented? A full Scheme should have vector-map, but in many implementations, this cannot be implemented efficiently in Scheme; should it be part of the base language?

> I don't fully understand what
> you mean by adequate, because I don't think you have
> yet explained yourself.

I want the base language to be a minimal Scheme that is still useful.
This primarily to make it easy to teach and learn.

This is not so well defined, I acknowledge. Possibly the minimal Scheme that is still useful has symbols, exact integers, lists, lambda, define, apply, map, for-each, call-with-current-continuation, error handlers, and that's all. Perhaps you add characters and strings. Perhaps you add vectors. Perhaps you make it all of R5RS but not much more. Perhaps you only include what's necesary to run the code in "The Little Schemer" and "The Seasoned Schemer".

Literal constants in programs are a problem. Perhaps you include all of them in the base language, but do not define any procedures on them (e.g., I can read a flonum, but I cannot do anything useful with it). Perhaps when you import a library module that defines a read that recognizes flonums, you signal to the program reader that it too should recognize flonums.

I am not against including the tools in R6RS, but they should be pushed off into the library. I think a good example of what I want is <complex.h> in C99. You cannot write this is "base C99" (the langauge part of C99 plus, say, <float.h>), so it has to be provided by the implementor. I would not object to the fixnum or flonum parts of SRFI-77 if they were available as a library module.

Nothing in SRFI-77 even
suggests that implementations are forbidden to support
exact integers beyond the fixnum range in their base.

SRFI-77 is fine. However, in your email you suggested that requiring "only the fixnum/flonum foundation" in the base language was attractive. I think the minimum you have to include is exact integers "large enough to index any list, string, or vector that can be created" along with arithmetic operations on these exact integers. Do you disagree?

From this, I think you either (a) define only the fixnum foundation and either make fixnums long enough or lists, strings, and vectors short enough that they are adequate for indexing or (b) allow fixnums and bignums and define generic arithmetic operations on them.

I find (a) unnecessarily restrictive. I prefer (b).

What we have to worry about are the systems that
provide nothing beyond modular arithmetic and
flonums.  Some implementors of those systems have
told me they do not want to support unlimited
precision integer arithmetic in their base language.
SRFI-77 was designed to make it possible to write
portable code that uses the full tower even in
systems whose implementors don't want to bother
with it.  All the implementors have to provide is
the fixnum/flonum base, and virtually all of them
can do that with little or no extra effort.

Let's consider a programmer that needs to use the full tower and three implementions:

(a) One that supports the full tower natively.

(b) One that supports only fixnums and flonums natively, but supports SRFI-77 and uses your code.

(c) One that supports only fixnums and flonums natively, does not support SRFI-77, but does have generic R5RS arithmetic. The programmer can then (define fx+ +), etc., and use your code.

Can a program distinguish (a) and (b)? Should it be able to distinguish (a) and (b)? How?

Are (b) and (c) different except in terms of efficiency? That is, are the fixnum and flonum parts of SRFI-77 anything more than the specification of the interface of your code with a Scheme implementation?

Perhaps SRFI-77 should be split in two; the flonum and fixnum parts would be one SRFI, primarily of interest to implementors who wish to use your code, and the exact and inexact parts would the other, primarily of interest to programmers.


Dr Alan Watson
Centro de Radioastronomía y Astrofísica
Universidad Astronómico Nacional de México