[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
response to new draft report (long)
Here are my (hasty) comments on the new draft Report.
COMMENTS ON THE TEXT OF THE DOCUMENT:
[page 1]
My name is "David Bartley", but "D.H.Bartley" is better than "D.Bartley".
Why use zero-origin indexing for section numbers?
[page 2]
Use italics and capitalization for consistency in "revised report
[29]" in 2nd paragraph of Background.
The term "coalescing" in the 2nd-to-last paragraph is not defined
anywhere.
[page 4]
Remove "will" from "Italicized names will stand for..."
Pluralize "argument" in "the append procedure is being passed zero or
more list argument."
Add "be" in "this report explicitly does not specify what value should
[be] returned." at end of 0.2.2.
Change "Upper and lower case letters are never distinguished..." in 1
to something like "Upper and lower case forms of a letter are never
distinguished...". Surely `A' is distinct from `b'.
Are #t and #f considered identifiers?
[page 5]
In 1st paragraph of 1.1: "Whitespace may occur..., but not within a
token." Is a string containing a space a token? The character `#\ '?
Typo: change `occuring' to `occurring'.
The statement "Backslash isn't used by Scheme except within string
constants" is awkward and negative.
Remove "are not used in Scheme right now but" from "... curly braces
are not used in Scheme right now but are reserved...".
Change "Like Algol or Pascal" to "Like Algol and Pascal".
[page 6]
In 2.1, the words "most values count as true, but a few--notably #f--
count as false" should be tightened up, since section 5.0 on page 13
makes it clear that only #f and the empty list count as false IN
CONDITIONAL EXPRESSIONS. (Is "in conditional expressions" a
qualifier???)
[page 7]
Fix "see section refdefine" in 3.0.2.
Is 3.0.2 a good place to take note that () is not a good procedure call?
What is meant by "here we will ASSUME that <body> is simply a sequence
of one or more expressions" in 3.0.3?
[page 8]
Please change the descriptions of COND and CASE to be what they were
in the RRRS (modulo the small changes we seem to have consensus on).
I see no reason to get carried away with describing the permissible
types for <datum> in a CASE key list. Just define CASE as using MEMV
(or EQV?) and let the implications hang out!
[page 10]
The first LET* example at the top left of the page is confusing, since
the first <binding> is decomposed into <variable> and <init> and the
others are not.
At the bottom of the first column, change the second instances of
<variable1> and <init1> to have subscript 2.
The words "... are variables which do not occur in the original LETREC
expression..." are confusing. Would a new binding of the identifier
(or is it variable) <temp1> be an occurrence of <temp1>? Similar
wording appears elsewhere in the document (e.g. with DO).
[page 11]
Specify that <name> in named LET must be an identifier (or is it
"variable").
[page 12]
Section 3.1.4: The wording "(for example, by a call to the FORCE
procedure)" begs for elaboration. I think it makes sense to postpone
most of the discussion to page 27ff, as JAR does, so let's use a
"white lie" here and mention only FORCE as a way to collect on a
promise. All other ways are extensions.
[page 13]
Change the last line of 4.1.0 from "Global definitions are essential;
all Scheme implementations must support them." to something like "This
semantics for top level definitions is essential." What does "global
definition" mean? The clause after the ";" is redundant.
I feel uncomfortable about using the term "lambda body" to include the
"body" of a LET or DEFINE expression, as is done in 4.2.
Why not retitle section 5 to be something like "Standard Procedures"
instead of "Initial Environment"? The text makes it clear that these
procedures are the standard bindings of variables in the initial
environment, so it doesn't have to be emphasized in the title. A
person looking at the table of contents on page 1 is likely to be
confused.
[page 14]
How about adding (EQ? NIL 'NIL) ==> #F as another example at the end
of 5.0 to hammer the point home?
Add "in the same order" at the end of "Two procedures are
operationally equivalent iff ... they return the same value and
perform the same side-effects." (Or is that implied by `having the
same side-effects'?)
The wording "it will always err on the conservative side" seems to say
that EQV? tries to do the "right" "wrong thing"!
[page 15]
Change "Objects of distinct types WILL NEVER BE operationally
equivalent, BUT FALSE and the empty list are permitted to be
identical..."
to "Objects of distinct types ARE NEVER operationally equivalent,
EXCEPT THAT #F and the empty list are permitted to be
identical...".
The second sentence of the description of EQUAL? should say that EQV?
is used for all objects except pairs, vectors, and strings.
[page 16]
Change "same" to "equivalent" in the comparison of (a b c d e) and its
dotted form.
[page 17]
APPEND! always side-effects all but its last argument.
[page 18]
Change "(in the sense of EQV? and EQ?)" to "(in the sense of EQ?)" or
"(in the sense of EQV?)". (Why mention both?)
What is meant by "returned" in the second and third sentences of the
description of SYMBOL->STRING? How about "created"?
[page 19]
The previous Report used all caps for the words NUMBER, COMPLEX, ...,
for EXACT and INEXACT, and [page 23ff] INT, RAT, FIX, FLO, ... . I
think that is less confusing than using the same typeface used for
Scheme identifiers.
[page 20]
Change the title of 5.4.2 from "Syntax" to something like "Number syntax".
Rephrase "to make all user populations happy". >I'm< not happy with
having both forms (e.g., both = and =?) and I'd settle for EITHER ONE!
[page 25]
JAR has omitted an important paragraph in the previous Report's
discussion of strings. The sixth paragraph on page 51 of the RRRS,
beginning "In phrases such as...", clarified in one place how
substring START and END work. The descriptions of SUBSTRING (etc)
don't make this clear at all.
[page 26]
If we only have SUBSTRING-MOVE-RIGHT! to support text editors, let's
flush it! This is only the tip of the iceberg when it comes to handy
little utility functions for building editors.
[page 27]
The dual use of VECTOR in the example starting (LET ((VECTOR (VECTOR...
is confusing.
For consistency, change ELTS in LIST->VECTOR to LIST.
[page 28]
Change "they" to "to" in "but they illustrate the property that the
value of a promise is computed at most once."
The second "bullet" at the top of the second column is not an
extension but an implementation issue (I think).
[page 29]
Restore the mention of the alternate name CALL/CC at the end of the
rationale for CALL-WITH-CURRENT-CONTINUATION.
[page 39ff]
Add index entries for `identifier' and `variable'.
------------------------------------------------
[Following are my responses to JAR's specific questions on language and
presentation. His question is left adjusted, my response is preceded
by ` ******* '.] I've omitted some questions/proposals I agree with
or have no comment on.
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?
******* Define it in terms of EQV? and define (EQV? '() '()) ==> #T.
******* This is consistent with Common Lisp's CASE, which uses EQL.
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.]
******* Don't share structure with any argument but the last.
Should APPEND and APPEND! explicitly allow any object as last argument
(CL compatible)?
******* Yes.
Should APPEND! disallow () as other than last argument?
******* No.
Can we specify that DISPLAY of a character does the same thing as
WRITE-CHAR?
******* Yes.
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.
******* Leave it as it is. It is `an error' not to terminate.
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.
******* Yes.
-----
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.
******* LAMBDA is what it's all about; but I don't really care.
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?
******* Use (LET () ...).
Should the complete presentation of FORCE appear up front with DELAY, or
delayed until the place where the entry for FORCE appears?
******* It's OK where it is, but see my comments above.
-----
Notes on LANGUAGE
The selectors in a CASE expression must be distinct.
******* OK.
I have left CASE and COND syntax as in RRRS: there must be at least one
clause, but it may be an ELSE clause.
******* Yes--I don't like the rewrite in the new draft.
BOOLEAN? is essential.
******* I suppose so.
No agreement on COND or BEGIN. I have left them as in RRRS.
[To do: fix the BNF to agree!]
******* Yes, but keep `test' instead of `guard'.
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.
******* Allow them.
The list to which the rest argument gets bound must be newly allocated.
******* Yes. Common Lisp screwed this up.
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.
******* Keep them both.
APPEND! necessarily clobbers its arguments (other than the last and
empty ones).
******* Yes. It's meaningless otherwise.
Many people wanted the number predicates pruned (i.e. choose between <
and <?). No agreement here, so both stay.
******* I still can't understand why we can't get agreement, but
******* having both forms is OK until we do. I'll live with either form.
The case sensitivity issue was a very sensitive one (so to speak). I
did not change the report's stance of symbol case insensitivity.
******* Let's remain case-insensitive.
-----
Notes on PRESENTATION
******* I agree with (or don't care about) the rest of the issues.
-------------------------------------------------
BTW, I generally agree with Will's answers to KMP's questions.
Regards,
David Bartley
-------