Scheme BNF

[Jonathan A Rees <JAR@MC.LCS.MIT.EDU>]

    Date: Mon, 24 Mar 86 10:39:14 est
    From: Kent Dybvig <dyb%indiana.csnet at CSNET-RELAY.ARPA>

    I think it should not work on vectors.  It makes sense to me only in non-
    constants, and until we make a firm statement that vectors have some useful
    meaning in Scheme other than as constants, backquote should not work within
    vectors.  I also have some amount of hesitance about splicing a list into
    a vector, etc., and what that would mean.

The RRRS doesn't say that backquote doesn't work on vectors; I'm only
suggesting a clarification.  I assume it would work as described in RRRS
and as in Common Lisp, which is that the thing returned by form in ,@form
must be a list, whose elements are spliced into the vector.

    I do not like the use of EQUAL?.  If you don't like <casable>, how about
    <atom>?  Seriously, we need some term anyway, since it is the same thing
    accepted by EQV?.  What about <simple>?  Or <tag>?

I'm trying to avoid introducing new nonterminals into the grammar, and
nothing fits; self-evaluating doesn't work, because strings are
self-evaluating and symbols aren't; there's already a <simple something
or other> for backquote, but it includes strings.

    Also, it's been said before, but I think we should allow for the optional
    syntax of a single "<casable>" not in a list.

          <case clause> ::= (<datum> <sequence>)

This complicates the grammar, and (() <sequence>) is ambiguous.  This
was discussed at Brandeis, and this version of case was accepted
unanimously after a somewhat painful discussion; I'm only trying to make
it more precise.

        - Oh yeah, I forgot to mention in my previous message that I would like to
        document DELAY and FORCE, as non-essential special form and procedure,
        respectively.  I believe they're non-controversial, and desirable given
        that they have a central role in S&ICP and are a little tricky to
        describe and implement.
        
    If you don't mind, please send out your prose for these and include the
    appropriate code for them.  I don't have them in Chez Scheme yet and I'm
    not in the mood to think.

There's a description and implementation in Structure & Interpretation.
I'll send out my prose with the rest of the manual next week.

    I am uncomfortable with the use of <sequence> in light of the existence
    of sequence as a special form.  

Why?  I chose the term precisely because the term "sequence" was already
in use this way.  But I'll try to think of something better.

				    Furthermore, I think that <expression>+
    would be more expressive where it appears, and in Scheme there should be
    no confusion with the operator + or sign +.

The + meaning at least one won't be confused with + meaning the
character or identifier + because it will be in superscript and in Roman
typeface.

I was thinking of changing the definition of <sequence> to be
<statement>* <expression>, to be a little more descriptive, and to
emphasize the fact that the last value of a <sequence> becomes its
value.  I think this nonterminal improves readability; if I were to get
rid of it I'd also want to dispose of <consequent> and several others.
Anyone else have an opinion?

Jonathan