Scheme BNF

[Guy Steele <gls@THINK-AQUINAS.ARPA>]

    Date: Sun, 23 Mar 86 20:38:01 EST
    From: Jonathan A Rees <JAR@MC.LCS.MIT.EDU>

[JAR's original message appears below only in excerpts.  I am working
with the AI Memo 848 version of RRRS, if that matters.]

    - Does anyone object to defining (COND) and (CASE) to return unspecified
    values?  I think this would be a good idea.

I think these cases already follow from the discussion on page 14, which says
that if no guard or selector is satisfied then the result is unspecified.
I don't object to drawing attention to these cases explicitly.

    - Shouldn't backquote work on vectors?  If not, then what's the rationale
    for making them work on lists and not vectors?

Yes.  I observe that backquote works on vectors in Common Lisp (but not on
structures, more's the pity).

    - What kinds of constants should be allowed in CASE clauses?  I don't
    really care, but I can imagine two possible answers:

    1. If EQV? is used for comparisons, then it doesn't make any sense to allow
    strings, lists, or vectors.

In the context of Common Lisp, it does make sense because one could use
backquote (for example) to construct a CASE expression with a cons cell
as a selector and then feed this expression to EVAL.  It probably makes
less sense in a SCHEME that does not have the ENCLOSE operation.

    - I definitely want like to flush the (<var>) syntax for iteration specs in
    DO.  It is inconsistent for DO to have this alternate form and not LET,
    and I don't like either.  Does anyone actually ever use it?

I have no strong opinion on this.

    - I would also like to flush the (<var> <init>) syntax for DO iteration
    specs.  Does anyone ever use this?  I always wrap the DO in a LET if I
    need extra bindings.  No replies from people who don't use DO, please.

I'm a user of DO, and I draw the following distinction when I write code:  a
variable bound by a LET wrapped around the DO is merely naming a quantity used a
lot within the DO, but that value will not change, whereas a variable bound in
the DO itself is explicitly updated by the DO loop using SET! (usually in the
body) in a way that is too complicated to be conveniently expressed as a step-form.


Regarding the grammar: (a) The handling of quasiquotation is very nice.  (b)
There is a confusion in the grammar: some parts of it deal in strings of tokens,
and other parts in strings of characters.  On the face of it it is unclear why
spaces can be interpolated to produce "(a b c)" instead of "(abc)" in the grammar
for a list but spaces may not be interpolated to produce "f o o b a z" instead of
"foobaz" in the grammar for a symbol.  The grammar should be divided in the usual
way into a character-based lexical grammar for tokens and a token-based parsing
grammar for expressions.

--Guy