[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Remaining questions & remarks (2)
=======> Here are my comments. I don't care all that much about the items
=======> I've skipped over. --David Bartley
1. BEGIN vs. SEQUENCE: this is a pretty glaring ugliness in the report
[...]
(a) leave things as they are (BEGIN essential with non-essential
synonym SEQUENCE),
(b) remove BEGIN and make SEQUENCE essential (noting in the Notes
section that BEGIN, like #!TRUE etc., should be supported by
those implementations which care about running code written in
the past year).
=======> I strongly prefer (a). BEGIN is the traditional name and is easy
=======> to understand (even without END). SEQUENCE is a *type* in Common
=======> LISP and is likely to cause confusion. I thought Hal and Gerry
=======> had indicated at Brandeis that they were willing to revise the
=======> book to use BEGIN instead of SEQUENCE. (Is my memory faulty?)
2. Similarly but less glaringly, we have a problem with the numeric
comparisons. Again, many people have said they don't care but they only
want one set, with or without question marks. Thus I offer
the choices
(a) leave things as they are
(b) flush the alternative names <? <=? >? >=? =?
=======> (b)
3. REC and NAMED-LAMBDA :
Again, I sense capitulation on the part of some who have been stubborn.
The only options permitted are:
(a) Keep both
(b) Flush both
=======> (b).
4. SUBSTRING-MOVE-LEFT! and SUBSTRING-MOVE-RIGHT! :
=======> Flush them.
5. Should we say anything about the possibility of parallel or
interleaved argument evaluation? Remembering something I thought I
heard Will once say, I added the innocent little phrase "or perhaps
in parallel" to the description of procedure calling. Richard
Kelsey quickly pointed out that if it's mentioned as being a
possibly legal implementation, many otherwise valid scheme programs
may fail to run in implementations which do this, because they won't
do necessary synchronization. I agree; this is acceptable only if
we provide synchronization primitives.
=======> Flush the reference to parallel evaluation. Keep random order
=======> evaluation.
6. Number input exactness:
=======> I haven't come to terms with exactness yet, so I don't have an
=======> opinion. Has anyone implemented this yet?
7. Must a port still be a port (i.e. answer true to INPUT-PORT? or OUTPUT-PORT?)
after being closed?
=======> Yes. (Maybe. (I don't know. (What a question!)))
8. Apparently there's no difference between ABS and MAGNITUDE. Should we
keep both? If so, should I change the presentation in any way?
=======> Flush MAGNITUDE; keep ABS.
9. ANGLE is what Common Lisp calls PHASE; any interest in changing the
name? ...
=======> Use PHASE.
10. Two-argument arctangent (ATAN Y X) is unnecessary, since its effect
can be trivially achieved by (ANGLE (MAKE-RECTANGULAR X Y)). Do we
apply Occam's razor and remove it? If it's retained, then I'll just
document it as being the same as (ANGLE (MAKE-RECTANGULAR X Y)).
=======> Is there any problem with precision here? I'll go with the
=======> consensus.
11. JINX says: if PROCEDURE? exists, then a portable printer can be written.
=======> As Dan points out, we need to make it clear whether a
=======> continuation object is a "procedure" in the sense of this
=======> predicate. If we call it CLOSURE?, as someone (Kent Dybvig?)
=======> suggested, then it should perhaps discriminate against
=======> continuations. Since it is implementation-dependent whether
=======> continuations are easily distinguished from closures, I prefer a
=======> PROCEDURE? that is true of both closures and continuations.
12. (if x 1) vs. (cond (x 1))
(a) Change IF expressions so that they return the value of the
second form if the first form evaluates to false. [TRUE]
(b) Change COND and CASE so that they return an unspecified value if
there is no ELSE clause.
=======> (a), as amended.
13. Many people would like to see the (define ((((a b) c) d) e) ...)
feature go away. S&ICP doesn't use it, and it has a rather complicated
syntax (look at the BNF for evidence). Vote keep or flush.
=======> Flush.
14. Status of LOAD not resolved. If, as I suggested, LOAD is only
to be syntactically valid at top level of a file, shouldn't it be
renamed to be INCLUDE ?
=======> I'm not sure what INCLUDE means to people. My intuition is that
=======> INCLUDE is a conditional LOAD---it is ignored if the specified
=======> files has already been loaded. LOAD is unconditional and more
=======> appropriate as a building block for smarter capabilities.
15. Page breaks and tabs are mentioned in the report (actually I guess I
added them - sorry), but there are no #\PAGE or #\TAB characters.
Can this be made consistent by documenting #\PAGE and #\TAB, or [...]
=======> Lump these under "other whitespace". I intend to treat them as
=======> in Common LISP.
16. If page breaks are documented, should the terminate comments? I think
they should (but of course they don't in Common Lisp).
=======> They won't if they are just whitespace.
17. Bartley says: "the second sentence of the description of EQUAL? should
say that EQV? is used for all objects except pairs, vectors, and
strings." Forcing it to use EQV? seems kind of random to me. This
would of course make my notion of "apparent equivalence" useless,
destroying what I deluded myself into thinking was an elegant symmetry
between EQV? and EQUAL?; maybe it's a bogus idea anyhow. I
intentionally wanted to be silent on this point, allowing EQUAL? to
return true more often than EQV? perhaps, but I don't care that much.
=======> I think that explicitly mentioning EQV? would clarify things.
=======> In particular, people want to understand how EQ?, EQV?, and
=======> EQUAL? are related. I think its easier to understand them if
=======> they monotonically become less discriminating; thus all things
=======> that are EQ? are also EQV? and EQUAL? and all things that are
=======> EQV? are also EQUAL?.
18. Several people have complained about Clinger's perhaps overly accurate
description of what happens when variables become bound. To be
accurate, we have to say that locations are created and the initial
value is stored in the location, but this doesn't sit well with the
desire to have Scheme sound like an almost-functional language.
What to do?
=======> Keep Will's description.
21. Should section numbers be zero-based? I'm beginning to think this looks
unprofessional; and it just doesn't look right in several places. It
worked well in the previous version of the report, and it's clearly more
consistent with the language (which is zero-based), but it doesn't work
the way I've reorganized things. If you like zero-based section
numbers, speak up.
=======> One-based.
23. I flushed the historical note "CATCH could be provided by a procedure"
sentence (again, because two or three people thought it was random and I
agreed), but some of you have complained about this. Why should this
bit of history be present, but not others that are at least as
important?
=======> We need to explain that CALL/CC is more than CATCH.
24. CALL/CC was mentioned in a sentence in a rationale in the RRRS. I
flushed the reference because (a) a number of people find the name
CALL/CC quite distasteful and (b) it is inconsistent to mention here
that some scheme implementations provide an alternate name for this but
not also do so for LABELS, BLOCK, and a zillion other things.
=======> Keep CALL/CC.
Language:
Only one empty list, period. (eq? '() '()) returns true.
=======> Yes.
A port does not become closed as a side effect of reaching end of file.
After end of file, you'll continue to read end of file objects as long
as the port is open. It's an error to read from or write to a closed
port.
=======> Yes. Yes. Yes.
DISPLAY writes characters like WRITE-CHAR does.
=======> Yes.
=======> Regards,
=======> David Bartley
-------