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

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?