[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
new, simpler formal specification
I recently wrote an alternative specification of Scheme's syntax using
(roughly) BNF, but in such a way that is much more in the spirit of
Lisp: the syntax of the external representation of S-expressions is
separated from the syntax of Scheme, and S-expressions are specified in
such a way as to resemble a recursive-descent parser as closely as
possible. That is not the point of this message, though. In writing
the alternative specification, I realized that S-expression comments
can be specified much more simply. Specifically, all it requires is
that the <datum>, <list>, & <vector> non-terminals be extended, and a
<commented datum> be introduced. (<Token> must of course be extended
with a "#;" option, too.) <Datum> becomes:
<datum> ---> <simple datum> | <compound datum> | <commented datum>
<commented datum> ---> "#;" <datum> <datum>
<List> & <vector> use a couple of auxiliary rules; they are all
<list> ---> "(" <datum>* <optional dot> <delimiter prefix> ")"
<optional dot> ---> <empty> | <datum> <delimiter prefix> "." <datum>
<vector> ---> "#(" <datum>* <delimiter prefix> ")"
<delimiter prefix> ---> <empty> | "#;" <datum> <delimiter prefix>
The first datum within a commented datum is ignored, as is any datum
immediately following the "#;" token in a delimiter prefix.
This formal specification is much simpler than what Al* Petrofsky
suggested earlier, and I think it should satisfy Paul Schlie's demands
for a grammar more consistent with Scheme's existing one. If no one
sees any problems with it, I'll change the SRFI document to use it and
finalize the SRFI, which is a bit overdue.
Should Paul Schlie still prefer his own specification, which I still
don't understand, he should provide an implementation of it in terms of
Scheme48's reader (as I show in the document), and he should explain
why he wants to so drastically change the various reader abbreviations,
those for QUOTE, QUASIQUOTE, &c., to magically disappear due to their
being in what was previously syntactically invalid locations.
(My alternative specification of Scheme's syntax, by the way, is at
those curious. Any comments, questions, or other feedback on it would
be appreciated, though such feedback should be sent to me directly, not
to this mailing list.)