[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Formal spec; implementation; nesting
On Mon, 10 Jan 2005, Alpert Herb Petrofsky wrote:
> >From draft 1.1:
> > -- Specification --
> > A new octothorpe reader syntax character is defined, #\;, such that
> > the reader ignores the next S-expression following it. For example,
> > (+ 1 #;(* 2 3) 4) => 5
> > (list 'x #;'y 'z) => (X Z)
> > An `S-expression' is defined as a full expression that READ may
> > return.
> That's a nice start at an informal specification, but, as the
> questions about nesting and spacing have already shown, you need to
> elaborate more,
Yes, I already put elaboration in the next revision to go up. (I ought
to have put it up sooner, I suppose.)
> and you need a formal specification too, in BNF, as in
OK, I'll add that in the next revision, too. (I wrote the initial
draft in haste. Why I did that I don't remember, but that accounts for
the lack of formality, which will be fixed soon.)
> In the "Implementation" section, you only provide four lines of code,
> which only make sense if you read the much larger section of text
> above them, and which only constitute an actual implementation if you
> combine them with the entire scheme48 read system, which I doubt is
> formally specified anywhere.
It was not intended to be an actual implementation (except to Scheme48)
-- it was intended to be a suggestion for how most S-expression parsers
could implement it. For that purpose, I think it suffices.
> That's helpful to scheme48 users, but why not also write an actual
> READ procedure that anyone can run against the given examples and
> against any examples they think of about which they have questions?
> It doesn't take a lot of code to do so in r5rs scheme: see the SRFI-38
> reference implementation (which is only 223 lines, and that includes
> numbering stuff you needn't bother with).
I planned on later including the rest of Scheme48's reader, which is
very simple to begin with (though not as minimalist as SRFI 38's), for
a complete example implementation that people can run easily.
> I suggest adding these two examples to the srfi, because they test two
> of the unusual states of a reader implementation (the after-the-dot
> state and the after-the-dot-and-the-following-sexp state):
> (a . #;b c)
> (a . b #;c)
OK, I'll add them. The results, for any impatient readers of this
mail, are the pairs (A . C) & (A . B).
In response to all of the hubbub regarding nested S-expression
comments, I have to wonder: how often do you write such nestings? Does
it really make so much of a difference that you consider 'fixing' a
slightly non-intuitive yet not very common use of S-expression comments
more significant than fundamentally changing Scheme's syntax to be
sensitive to whitespace tokens? Is it really so significant as to
warrant inhibition of simple recursive-descent S-expression parsers?