[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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?