I apologize if this shows up twice.  I thought I had sent it
to srfi-77@srfi.schemers.org, but it hasn't shown up yet so
I probably omitted that email address.

Dr Alan Watson wrote:
> Would it be correct to say that you want the base language to include
> all of the tools necessary for building a "full" Scheme?

Yes, that happens to be my personal preference, but I don't want
to argue for that except in the case of arithmetic.  Arithmetic
is an important part of any programming language, and has a huge
impact on portability, reliability, and performance.  It is also
hard to get arithmetic literals and i/o right unless the base
language provides adequate primitives.

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

It's more complicated than that.  I don't know what will happen
with the R6RS.  I hope it will mandate the full tower.  Even if
it does, many implementors will still need help from a portable
implementation of the tower; otherwise they may ignore the R6RS,
or give up on implementing Scheme altogether.  While it is true
that the primitives assumed by a semi-portable implementation
do not have to be required by the R6RS, those primitives will
be so close to the fixnum and flonum operations that several
implementations already provide that it would be silly not to
improve portability further by standardizing those operations.

> 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?

Ideally, yes.  The i/o SRFIs seem to be making progress in that
direction.

> 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?

In my opinion, efficiency is an argument for putting something
into the base language if there is some fundamental reason why
that thing cannot be implemented efficiently in terms of the
rest of the base language.  Efficiency is not an argument for
putting vector-map into the base language, because vector-map
can be implemented efficiently in Scheme.

If some system has performance problems that would cause
vector-map to be slow if implemented in Scheme, then that
particular system is free to implement vector-map in some
other language.  As language designers, it would be silly
for us to become overly concerned about the efficiency of
programs that run in gratuitously slow systems.  If the
users of those systems were seriously concerned about
efficiency, they would be using a more efficient system.

> 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?

Yes.  SRFI-77 says "We assume that Section 6.2.3 ("Implementation
restrictions") of R5RS remains essentially as it stands."  In
particular, R5RS section 6.2.3 already says "An implementation
of Scheme must support exact integers throughout the range of
numbers that may be used for indexes of lists, vectors, and
strings or that may result from computing the length of a list,
vector, or string. The length, vector-length, and string-length
procedures must return an exact integer, and it is an error to
use anything but an exact integer as an index."

When I say that requiring only the fixnum/flonum foundation is
an attractive option for R6RS, second only to requiring the
full tower, I certainly do not mean to imply that systems
would be forbidden to support numbers that are neither fixnum
nor flonum.  In particular, I do not mean to suggest dropping
the part of R5RS section 6.2.3 I quoted above.

> 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?

No, apart from whatever incantation may be involved in activating
SRFI-77 for system (b).  No.  No way, apart from the need to
incant whatever incantation may be involved in activating SRFI-77
for system (b).

> Are (b) and (c) different except in terms of efficiency?

They don't even have to be different in terms of efficiency.
In most of today's most efficient implementations of Scheme,
all but the fixnum/flonum base is written in Scheme.

> 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?

Yes.  Many Scheme programs, e.g. the nucleic benchmark, use
type-specific fixnum and flonum operations.  Many implementations
of Scheme support such things, with relatively minor differences
in semantics and naming.  When such extensions are so widely
supported and used, they become candidates for standardization.

Will