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.

Regards,

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