[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
My comments on the R^RS
Jonathan,
I've enclosed my comments on the R^3RS in this note
separately from my answers to your specific questions you asked.
Hope this helps. By the way, I know that putting this all together
involves a lot of work (and sometimes a lot of refereeing), and you
should be aware that your contribution isn't going unappreciated. Thanks
for all the hard work you're putting in, and my apologies in advance
if I err here due to an insufficiently detailed reading of the report.
asc
------------------------------------------------------------------------
1. I am concerned that we have multiple conflicting goals in the
design of the document. Sometimes it is a reference manual,
and sometimes it is a technical report, and sometimes it is a
users' guide. Perhaps we must live with this if there is to
be only one report, but it might be a good idea to try to
separate out (say) the history from the reference manual parts.
This is reflected in the discussions about moving or removing
the history section, for example.
2. As you might expect, I would like to see a somewhat more vigilant
attitude in warding off the dark forces of Common Lisp. It is not
compatibilities or incompatibilities that are gratuitous; it is
the very act of being concerned with compatibility at all that is
gratuitous. We should have our own standards of what a good LISP
looks like and stick to them. The first job of a good language is
to be a good language, not to be just like another bad language
that's familiar (nor even just like another good language that's
familiar). Common Lisp's goals were nearly the opposite of
Scheme's, and however good a job the CL committee did, we owe them
no homage. I recognize that this is more an issue of the design
of Scheme than of its documentation in a report, but there seems
to me to be entirely too much concern for similarities and
dissimilarities w.r.t. Common Lisp in the report. It may be
appropriate to discuss the topic of Scheme vs. CL briefly in the
historical section, but there should be a very clear message to the
reader that CL followed Scheme -- and continues to, in the sense
that Scheme is meant to be a progressive attempt at (LISP) language
design rather than a codification and standardization of existing
ideas in prior LISPs. The CL people should be writing reports
that compare their work to ours, not the other way around. ``Let
them eat cake.'' [OK, flame off.]
3. On p.2 you list me as a Brandeis participant. Would that it were
true. I will leave to your judgement whether I should be listed
in the acknowledgements, as an author, or otherwise.
4. I agree with both your observations on the Syntax section (0.1)
-- that it makes sense to have one there and that it isn't clear
what it should say. Perhaps a fairly terse or brief description of
Scheme's simple syntax would do, e.g.
The syntax of Scheme, like that of most LISPs, provides
for great expressive power, largely due to its simplicity.
An important consequence of this simplicity is the
susceptibility of Scheme programs and data to uniform
treatment by other Scheme programs. As with other LISPs,
the ``read'' function actually parses its input; that is, it
performs syntactic as well as lexical decomposition of what
it reads, rendering input in a uniform internal representation
and making it particularly easy to manipulate Scheme programs
and data in a correspondingly direct and uniform fashion.
Scheme employs a parenthesized-list Polish notation to
describe programs and (other) data, with lists recursively
defined as being composed of lists and what are
sometimes referred to as ``atomic'' objects (numbers,
symbols, etc.) \foot{Unlike most LISPs, Scheme does not
explicitly provide a predicate for assessing atomicity,
although it does contain predicates for determining whether an
object is a list, symbol, number, etc.} The syntax of Scheme
expressions is described formally in greater detail later in
this report.
5. Identifiers & keywords: Sections 1.0 and 2.0 gave me pause,
because I have been concerned for some time with the keyword
problem in Scheme (and I admit to being dissatisfied with the
most common solution). The statement
``Any identifier which is not a syntactic keyword may be
used as a variable....''
which appears in both sections implies that there are keywords in
the language, although (a) there aren't guaranteed to be and (b)
you haven't said anything previously about keywords in the
document. The astute reader will then turn to the index to find
out what she has missed, only to discover that there is no entry
at all for keywords. Later on there is a discussion of keywords,
but it is essentially an afterthought, and by now the reader may
have decided that Scheme really is Pascal after all (Andrew, bite
your tongue). Something needs to be done to clear up the
potential confusion from the initial presentation of identifiers
vs. keywords. The inline "Note:" on p.6 probably does not serve
to clarify things as much as it might.
6. P. 6, SS 2.0: Yes, mention that there are no guarantees that a
``top-level'' exists. (Then encourage the rest of the RRRRS
authors read that paragraph....)
7. SS 2.1, p.6 implies that there are other values besides #f that
count as false. Except for the optional #!false, I'm not sure I
see what these are. Perhaps you count things like (NOT #T) as
false for the purposes of this section?
8. p. 7, SS3.0.2 -- Typo at bottom of page, ``combinations. .''
9. p.7 SS 3.0.2: It may not be clear to non-LISPophiles what
``+`` evals to, or why ``+'' gets evaluated in the example
(+ 3 4) => 7
((if #f + *) 3 4) => 12
The idea of a function name evaluating to a functional object
will not be intuitive for most readers, who probably think in
languages that don't have first-class procedures. Perhaps
something can be done to make this clearer.
10. There are a few minor report points that reflect major
underlying problems we really have yet to solve in the design
of Scheme, involving things like COND, IF, and perhaps LET. The
syntax definitions provided earlier on in the report make (COND ((X)))
a legal expression, and we've already had the n-armed IF argument.
Similarly, (LET () (DOSOMETHING)) is legal, although perverse and
not obviously useful. (The latter expression actually appears in
the report, at the top of p.10 col2, although I can see no reason
to have used it -- the example would have worked fine without it.)
I think what has happened is that we never resolved the issue of
``functions'' that don't return values. Instead we developed, or
permitted the random evolution of, a hodgepodge of mutually
inconsistent local solutions: DEFINE is not an expression, IF may
(or may not) have an undefined return value, (COND ((X))) returns
(X), etc. We still have design work to do.
11. On a related syntax (or is it design?) point, on p.9, SS3.1.0, the
expression (CASE TEST (() (FOO))) is permitted. It's not clear to me
why we want to permit this, nor what it means if we do. Strictly,
it would always be ignored, in which case it's spurious.
Similarly, (CASE TEST) is legal; strictly it returns <unspecified>
but seems senseless nonetheless.
12. I cannot refrain from observing that DO is truly ugly, a
veritable pig of a construct, and we could have done better.
We are indeed fortunate that its use under practical circumstances
is rarely necessary.
13. The Note: on p.11 about DO in which you describe assignment vs.
rebinding is guaranteed to be lost on the majority of readers.
An example of how it differs from other LISPs' DO might help.
14. On p.12 where QUASIQUOTE is introduced, as a purely typographic
observation, we really need a better backquote character. It's
very hard to read the character at all in the copy of the report
I have, especially at that point size. At first glance I thought
in all honesty that it was a speck of ink on my copy. (I believe
my hardcopy came from MIT, although its route was sufficiently
mysterious that it might have been printed at Berkeley instead.)
15. SS 4.0 talk about the ``top level,'' as if there is one; cf. my
point #6 above.
16. SS 4.1, p.12, first sentence: I find this ambiguous:
Definitions are not valid in all contexts where expressions
are allowed; they are only valid at the top level [sic] of
a <program> and at the beginning of a lambda body.
This could mean any of several things, e.g.:
Definitions are invalid in all contexts where expressions are
allowed (i.e. there are no contexts in which definitions are
valid where expressions are allowed)....
or
Definitions are invalid in some contexts where expressions
are allowed (i.e. there exist contexts where expressions are
allowed but wherein definitions are not allowed)....
This probably needs to be rephrased for people who don't already
know what it's trying to say.
17. Top of p.13 col1: You have ``(. <variable>) would be understood
to mean simply <variable>.'' Why permit this? It offers no
additional functionality and strikes me as an unclean misfeature.
18. p.14, SS 5.1: Misspelling, ``distint'' => ``distinct''.
19. p.17, SS5.2: Misspelling, ``decsription'' => ``description''.
20. Predicates: As far as I could see, we never actually commit to
putting ``?'' at the end of predicates, although we do
mention on p.18 that functions like ASSV don't end in ``?''
because they aren't predicates. This convention would be a good
thing to assert. (It also would blow the people who dislike >?
out of the water, I'm afraid.)
21. p. 18, SS 5.3, First sentence: ``entirely'' is massive
overstatement here. There are lots of bases for the utility of
symbols -- like their use as printable undoublequoted objects, which
seems to me to have been lost almost entirely [sic] on the
Scheme community (hence the rejection of upper/lower case
distinction). (Incidentally, CommonLisp also gets control of
UC/LC terribly wrong, to my eternal annoyance when I build
distributed multiprocessing mostly-LISP-based systems that want
to communicate by passing case-varying symbol tokens instead of
strings.)
22. p.28, SS 5.8: What happened to TeX in the middle of column 2
where it says ``The escape procedure''? Misplaced manual
linebreak, perhaps.
23. NOTES, p.35ff.: This material should stay somehow. We need to
make it clear that R^3 Scheme is not being touted as Yet Another
Ultimate Solution To The Programming Language Problem, but rather
as a snapshot of a *process* of good design, for which not all
answers have yet been found. We also ought to use the opportunity
for publicity afforded us by SIGPLAN to advertise some of the thorny
unsolved problems that need further research, and encourage
language designers to work on them.
-------------------------------------------------------------------------