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