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)
|
> From: Taylor Campbell <xxxxxx@bloodandcoffee.net> > This is absolutely ludicrous and absurdly derogatory of how Lisp > readers do and always have worked. ... - ok, how does a "lisp" reader parse a recursive lexically scoped comment of the form specified by the grammar: <block-comment> -> #| <all-chars-excluding-#|-and-|#> |# Which by the way does specify an arbitrary recursive lexical scoped comment which is delimited by #| ... |#, as the next sequentially encountered #| is excluded from <all-chars-excluding-#|-and-|#>, which then begins another embedded <block-comment>; or encounters a |#, which terminates it. Just as a recursive list bounded by () may specified. - I believe you'll find that any parser, lisp or otherwise will tend to either pre-process it away (as cp does for c), or simply consume it as white-space during the parse. As given the grammar specification: <delimiter> -> <white-space>+ | <whatever> <white-space> -> <white-space-char> | <block-comment> <block-comment> -> #| <all-chars-excluding-#|-and-|#> |# <token> -> {ignore <white-space>} <something> {look-ahead <delimiter>} The parser will most likely: - ignore <white-space> until it finds the beginning of <something> - accumulate <something> until it fines the beginning of <delimiter> - then returns returns the <something> Where now applying the same methodology to: <datum-comment> -> #; <datum> It seems fairly clear to me that #; should be properly interpreted as beginning a <datum-comment> which either delimits an existing parse, or is ignored as <white-space> searching for the next valid token. Where since #; is not specified as beginning a <datum>, #; #; is invalid. Where if you want to give #; #; <datum> some meaning, you'll have to specify the grammar such that: <datum-comment> -> #; <something> where <something> may itself begin with a #; as otherwise #; #; would not be acceptable as a valid sequence as specified by the grammar. (given that it seems I've both upset you, which was not my desire, and am personally tired if this debate, as I'm sure you and others are; I'll not attempt to pursue the matter any further to all our benefit). thanks, -paul-