[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: new, simpler formal specification

This page is part of the web mail archives of SRFI 62 from before July 7th, 2015. The new archives for SRFI 62 contain all messages, not just those from before July 7th, 2015.

Ok, now I understand the problem, you're trying to justify a refinement
of scheme's grammar based upon the limited facilities available within
scheme48 at the user level, rather than refine it's parser code. Given
your description in the proposal's text:

"Though there is no portable manner by which to extend Scheme's reader,
 the #; syntax is trivial to implement.  The procedure associated with
 the #\; octothorpe reader syntax character could simply first call READ
 to consume the following S-expression and subsequently call an internal
 procedure that reads either the following S-expression or a delimiting
 token, such as a closing parenthesis."

To which I'd observe that this is not likely a reasonable basis for any
grammar extension proposal; especially those attempting to extend the
definition of <comment> which is semantically treated as <whitespace>,
and delimited by lexical symbols and syntax which are not legally
expressible in parsed s-expressions (therefore should be presumed to be
implemented within the reader's parser where the raw lexical structure
of the program is visible, just as <line-comments> and <block-comments>
should be similarly handled, not based on the coincidental semantics
which result from a user level hack leveraging the ability to intercept
tokens beginning with a #, as opposed to properly trying to extend it's
the reader's implementation of comment parsing.

In summary, please consider the simple addition of extending the definition
of <comment> to include <datum-comment>; in turn treated as <whitespace>:

  <datum-comment> -> #; <datum>

Where it simply denotes that it and the following <datum> is ignored,
and an error if no <datum> follows. (i.e. #; #; is an error, as I believe
you had previously proposed, as it's not likely useful or consistent with
the grammar to treat it otherwise, regardless of what may fall out of a
user level scheme48 hack, as I and likely most certainly wouldn't expect a
lexical symbol to affect the interpretation of an expression beyond the one
immediately following it as written, and would only likely result in
unintended results otherwise.)