First, let me point out that I'm having a lot of difficulty trying to
decipher your English, which is extremely obscure and in many cases
grammatically invalid.  If you wish to continue, I'm not going to spend
any more excesses of time trying to pick through your comments for the
interpretation you might have meant, so please try to make your English
more understandable.  Ordinarily, I'm loath to be at all picky about
invalid grammar or other such issues, but the time it is taking to try
to understand your comments is getting ridiculously absurd.

On Wed, 23 Mar 2005, Paul Schlie wrote:

> > One problem with this is that it creates mutual references between
> > sections 7.1.1, which describes the lexical structure, and 7.1.2, which
> > describes the external representation of S-expressions -- in terms of a
> > stream of tokens.  While I find the 'stream of tokens' model very
> > distasteful to describe Lisp syntax, it is nevertheless how the current
> > framework for Scheme's syntax works, and breaking it is not a good idea
> > -- especially since you seem opposed to such massive changes anyway, or
> > at least that was the impression I got from your previous objections.
>
> - I'm honestly confused, the above representation is fully consistent with
>   R5RS

No, it's not.  As explained in section 7.1.1, that section describes
how tokens are formed from sequences of characters, and section 7.1.2
describes how S-expression data are formed from sequences of tokens.
Unless you interleave the translation from text to tokens and the
translation from tokens to S-expressions, it would break the existing
framework to introduce S-expressions (i.e. <datum>) into the section
that defines the formation of tokens.

>   (your proposal isn't with either, as it doesn't properly classify "#;
>   <datum>" grammatically as a comment, which it is both syntactically and
>   semantically inconsistent, with it needs to be parsed as <whitespace>. I
>   apparently need to be more explicit, given it's effective specification:
>
>   <whitespace> -> [ <whitespace-character> | <comment> ] <whitespace>
>
>  (which is the grammatical vehicle used to denote that comments are ignored)

Even R5RS resorts to English text to describe how intertoken space,
which includes comments, works.  It is not unreasonable, then, to add a
note about the behaviour of the contents of <commented datum>, since
this information is not conveyed at all by the BNF, and since the
definition of <commented datum> cannot be placed in the same position
as that of <comment> (i.e. as intertoken space).

> > (Your block comments are also inconsistent with SRFI 30, by the way,
> > but that is not relevant to this SRFI.)
>
> - how? other than being simpler, it seems fully consistent with it's text?

As I said, it is not relevant to this SRFI.  The BNF you showed,
however, does not allow nested block comments, while SRFI 30's _title_
is 'Nested multi-line comments.'

> >                                                                 First,
> > consider the text '#; A B'.  If parsed as a datum, the value will be
> > just B, since the '#; A' is considered intertoken space.  (This follows
> > straightforwardly since A is a datum, and so the text '#; A' satisfies
> > your <datum-comment> rule.)  So the whole of '#; A B' is one datum (as
> > defined in R5RS section 7.1.2).  If we then attempt to parse '#; #; A B
> > C' as a datum, we see that there is some intertoken space first, namely
> > #; followed by a single datum.  Since we determined that the text '#; A
> > B' qualifies as one datum, '#; #; A B' must be one datum comment, and
> > the only item remaining in the input stream is C.  Thus '#; #; A B C'
> > reads as the symbol C.
>
> - candidly haven't a clue of how you believe a recursive parser parses the
>   above grammar, but it simply specifies that: (given <ws> :: <whitespace>)
>
>   "#; #; A B C" :: "<error> <ws> <A> <ws> <B> <ws> <C>"
>
>   (as the grammar only specifies a legal parsing of "<#;> <datum>" as a
>    <comment> => <whitespace>, therefore "#; #;" is not a valid sequence,
>    as <#;> may not validly begin a <datum>, therefore a parse error.)

This is incorrect.  First of all, you can't represent the input as a
stream of tokens like you are trying to do here, since your grammar
interleaves the token & datum construction.  Because of this, your
explanation has an entirely flawed basis and therefore doesn't hold.
If you'd like to convince me that my interpretation of your grammar is
wrong, please single out the exact point where I start going wrong.

>   The reason you're having difficulty trying to cleanly specify:
>
>    " The first datum within a commented datum is ignored, as is any datum
>      immediately following the "#;" token in a delimiter prefix. "
>
>    is that it's a lousy inconsistent semantic behavior to try to specify,
>    vs. one more consistent with the language and recursive decent grammars:

Justify that assertion.  I don't buy it.