Remaining questions & remarks (1)

[Jonathan A Rees <JAR@MIT-AI.ARPA>]

I included the following with the reports I sent and gave out.  Here it
is again for those people who don't have it already.  It enumerates most
of the remaining nits I have.  Don't be intimidated by the number of
items; none are serious.  Many of these questions have been discussed
and some have been resolved already.  For those items that stay
unresolved, I'll take the conservative position and leave the new report
in agreement with the old report.

I'll send a second, more recent set of nits separately.

- Jonathan

-----

Questions on LANGUAGE

I left CASE as is, using EQV? as the comparison, and I explicitly stated
that the object ought to be boolean, character, number, or symbol.  But
shouldn't it allow empty lists, vectors, and strings, too?

May structure be shared in cases like (APPEND '(A B) '()) , or should APPEND
be Common Lisp compatible?  [Bartley says sharing would be a gratuitous
incompatibility with CL, I'm invlined to agree.]

Should APPEND and APPEND! explicitly allow any object as last argument
(CL compatible)?

Should APPEND! disallow () as other than last argument?

I decided that allowing GCD, etc. of Gaussian integers was probably
premature.  I'll put them in if someone writes the documentation
(including examples).

Can we decide on what to do about number exactness on input?  How about:
inexact if there are digits following a decimal point, or if exponential
notation is used.  Otherwise exact.

Can we specify that DISPLAY of a character does the same thing as
WRITE-CHAR?

What should be said, if anything, about the desirability and/or legality
of EQUAL? failing to terminate?  Rozas thinks an implementation with
this property is in error.

In light of the vagaries of CALL-WITH-xxPUT-FILE, perhaps it
would be a good idea to explicitly state that closing a closed port
should be a no-op instead of an error.

-----

Questions on PRESENTATION

Should the various examples which use DEFINE be changed to use the
(define (foo ...) ...)  syntax instead of (define foo (lambda ...))?
Several people have told me that all those LAMBDA's could unnecessarily
intimidate SIGPLAN readers.

There are two places (in descriptions of let* and letrec) where it is
necessary to create a lambda body in a context (such as the tail of a
BEGIN) where there isn't one already.  What is the cleanest way to do
this?  Is (let () ...) ok, or would ((lambda () ...)) or something else
be better?

Is the word ``promise'' all right for objects returned by DELAY?

Should the complete presentation of FORCE appear up front with DELAY, or
delayed until the place where the entry for FORCE appears?

-----

Notes on LANGUAGE

The selectors in a CASE expression must be distinct.

I have left CASE and COND syntax as in RRRS: there must be at least one
clause, but it may be an ELSE clause.

BOOLEAN? is essential.

No agreement on COND or BEGIN.  I have left them as in RRRS.
[To do: fix the BNF to agree!]

The RRRS explicitly allows internal definitions in the body of a LETREC.
They are scoped to the body only, not to the entire expression.  I can
flush this "feature" if a movement arises to do so; it seems sufficient
to me to permit only expressions (not definitions) in the body.

The list to which the rest argument gets bound must be newly allocated.

Making LET* be essential was suggested, but there was resistance to
this, so I left it as is.

There was strong sentiment both for removing REC and for removing
NAMED-LAMBDA.  However, the sentiment was not unanimous.  I don't
understand why it should have matterred so much, since neither is an
essential feature.  If these are present, shouldn't everyone's favorite
features be present too?  ... Supporters of REC included Kent Dybvig and
Dan Friedman.  Supporters of NAMED-LAMBDA included Jim Miller and Henry
Wu.  In addition, Bill Rozas insisted that if REC stayed, then
NAMED-LAMBDA must stay too, but he was willing to see both go.

APPEND! necessarily clobbers its arguments (other than the last and
empty ones).

Many people wanted the number predicates pruned (i.e. choose between <
and <?).  No agreement here, so both stay.

The BNF says that ALL random symbols, including ELSE, =>, UNQUOTE, and
UNQUOTE-SPLICING, are reserved and may not be used as variable names.  I
hope this is OK with everyone.

Note that the grammar for numbers allows one to write things like 23##
for inexact numbers.  This was implicit in last summer's report, and I
thought it wouldn't make sense if this was allowed on output but not on
input.

The case sensitivity issue was a very sensitive one (so to speak).  I
did not change the report's stance of symbol case insensitivity.

-----

Notes on PRESENTATION

I listed myself as "editor" of this version.  I probably should just
remain a coauthor, but the report needs an editor in order to look like
the Algol 60 report.

I eliminated the term ``special form.''  I introduced phrases like ``IF
expression'' in a couple of places; things like IF and CASE are not
referred to as active agents (keywords don't refer to particular
things---it's the evaluator that actively interprets expressions having
certain special syntactic forms).  I removed statements like
``<expression> is evaluated but <variable> is not.''

At Pitman's request, I changed ``guard'' to ``test'' in the description
of COND because ``guard'' has inappropriate connotations; COND doesn't
really implement a Dijkstra guarded conditional.

The term "variable" now refers the name itself, not the binding or the
location.  This is in accordance with the way logicians (including
Alonzo Church) use the term.

I decided not to add an appendix describing S&ICP differences.  The most
important difference, I think, was RRRS's lack of DELAY and FORCE.  I no
longer find the presence of SEQUENCE distasteful.

I removed the apologetic statement that went with the description of T
and NIL.  (Some people actually like T and NIL.)

The sentence ``This procedure can be very confusing if used
indiscriminately'' in the descriptions of set-car! and set-cdr! was
struck at Chris Hanson's request; it seemed gratuitous.

There are at least sixteen different references to Common Lisp.  I'm
going to try to remove some of them.  We have to make it very clear that
Scheme is 11 years old and originated some of CL's ideas --- not the
other way around!