Email list hosting service & mailing list manager

new, simpler formal specification Taylor Campbell (22 Mar 2005 22:56 UTC)
Re: new, simpler formal specification Paul Schlie (23 Mar 2005 01:49 UTC)
Re: new, simpler formal specification Taylor Campbell (23 Mar 2005 03:02 UTC)
Re: new, simpler formal specification Taylor Campbell (23 Mar 2005 05:59 UTC)
Re: new, simpler formal specification Paul Schlie (23 Mar 2005 17:00 UTC)
Re: new, simpler formal specification Taylor Campbell (23 Mar 2005 21:26 UTC)
Re: new, simpler formal specification Paul Schlie (23 Mar 2005 21:22 UTC)
Re: new, simpler formal specification Taylor Campbell (23 Mar 2005 22:48 UTC)
Re: new, simpler formal specification Paul Schlie (24 Mar 2005 01:06 UTC)
Re: new, simpler formal specification Taylor Campbell (24 Mar 2005 02:35 UTC)
Re: new, simpler formal specification Paul Schlie (24 Mar 2005 05:37 UTC)
Re: new, simpler formal specification Paul Schlie (24 Mar 2005 15:57 UTC)

Re: new, simpler formal specification Paul Schlie 23 Mar 2005 21:22 UTC

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