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

if, mapcar, mapc, ...



This note proposes a few significant changes and corrections to
the draft of the "Revised Revised Report".  Let me know if I have
misread the consensus.

I am moving to Oregon in two weeks.  I expect June will arrive
before I have finished typesetting this thing.

				William Clinger

----------------------------------------------------------------

Following the Algol 60 report, I propose that all attendees at
the Brandeis workshop be listed as authors.  The acknowledgements
will list other participants in the discussion over the network,
and I will sign an editor's note accepting blame for errors in
transcription and interpretation.

Chris Hanson's revised report on strings will be incorporated.

In resonse to a few complaints, I would like to replace the last
paragraph in Section I.0 ("Brief history of Scheme") with:

    Scheme shares with Common Lisp [\ref] the goal of a core
    language common to several implementations.  Scheme differs
    from Common Lisp in its emphasis upon simplicity and
    function over compatibility with older dialects of Lisp.

To allow for less error checking in compiled code, in the
discussion of variable references in section II.1 "An error is
signalled if {\it variable} is unbound" should read "It is an
error if {\it variable} is unbound".

Two-armed if will change from essential to optional status.

In the discussion of cond, "The special keyword {\tt else} may be
used..." should read "The keyword or variable {\tt else} may be
used...".

define! and defrec! will be flushed altogether.

The rationale for set! will be flushed.

In the header line for backquote, "macro special form" should be
"special form".

The initial value for nil (if it is provided at all) should be
#!null rather than #!false.

Several people have asked that append! not be allowed to side
effect its last argument, so unless there is opposition that
change will be made.

See my separate note for the proposed lexical syntax of numbers
and some questions that I have concerning numbers.

There is a problem with object-hash and object-unhash.  People
might want to ask themselves whether object-unhash is really useful.
The following scenario will be added to the rationale:

	>>>(define x (cons 0 0))
	x
	>>>(object-hash x)
	77
	>>>(set! x 0)
	...
	>>>(gc)		; garbage collection occurs for some reason
	...
	>>>(object-unhash 77)
	???		; ill-defined: #!false or (0 . 0)

The name of mapcar will be changed to map.  (There seems to be a
fair consensus for this.)

The name of mapc will be changed to for-each.  (There seems to be
a fair consensus that it should be changed, and for-each seems to
me to be the best name that has been proposed.  At any rate it is
the only name that has been proposed that has not drawn
objections.)

call-with-current-continuation is essential.  That it was not so
indicated in the draft was a gross blunder.

The introductory material for call-with-current-continuation will
be moved to the rationale.  The last sentence of the rationale,
which begins "Some people think...", will be changed to read
"Although the name is descriptive, some people feel it is too
long and have taken to calling the procedure call/cc".

The original explanation of call-with-input-file and
call-with-output-file allows the port to be closed on any throw.
This makes it impossible to use escape procedures in a portable
manner.  The sentence beginning "If the current continuation ever
changes in such a way as to make it doubtful that the procedure
will return..." will therefore change to "The implementation must
not close the port unless it can prove that the port will never
again be used for a read or write operation."

eof? will be renamed eof-object?

listen? will be renamed char-ready?.  (Everyone agreed that the
name should be changed, but there was little agreement on the new
name.  No one seemed to care very much either.)  It will be
required that if char-ready? returns #!true, then the next
read-char operation on the port must not hang, and it will be
pointed out that this has implications for the way that rubout
handlers are written.

It will be required that the load procedure does not affect the
values returned by current-input-port and current-output-port.

There are many small improvements and corrections to be made
also, but I won't bore you with them.  (The above should
suffice.)