Scheme BNF

[CPH%OZ.AI.MIT.EDU@XX.LCS.MIT.EDU]

    Date: Sunday, 23 March 1986  20:38-EST
    From: Jonathan A Rees <JAR at MC.LCS.MIT.EDU>

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

I think that the only reason for this is that the #(...) syntax for
vectors was originally self-evaluating, which implied that the
contents of the vector was already quoted.  If this requirement is
flushed (I don't know if there is consensus for this, but I would like
it to be), then I think that backquote should work on vectors also.

    - 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.

    2. Use EQUAL? for comparisons, and allow any <datum>.
    ...but I won't listen to anyone who doesn't
    supply a better word to use for the nonterminal than "casable".

I suspect that "casable" should be spelled "caseable".  I don't think
that counts as a better word, but I hope that you'll read my comments
anyway.  (Otherwise I suppose I'll have to invent a new language so
that someone will listen to me.)

A fine point I would like to make is that RRRS is careful to allow the
possibility of immutable strings.  In this case I think that EQV?
makes sense on strings, so that (sigh) an even more complicated syntax
would be needed which took into account that possibility.

On the other hand, I like the idea of using EQUAL? and I agree that it
is easy to make efficient.

However, just to complicate things, I'll mention something about CASE
that has bothered me when I have tried to use it.  I sometimes have
found that I am doing something of this kind:

(COND ((EQ? X 'FOO) ...)
      ((EQ? X BAR) ...)
      ((EQ? X 'BAZ) ...)
      ...)

where one of the keywords I am matching against has been parameterized
for one reason or another, and this forces me to use COND rather than
CASE.  Has anyone else run into this problem?  Is it interesting
enough to consider modifying CASE?

    - 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?

Actually, MIT Scheme has a consistent meaning for both of these, which
is that the variable in question is bound but not assigned.  Such
variables are only useful in the presence of assignments, and it is an
error to refer to one between the time that it is bound and when it is
assigned.  I suspect that some will find this offensive, although
personally I find it preferable to other alternatives that I have seen
for describing this particular state.  So I'm just pointing it out for
general interest.