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