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)
|
On Wed, 23 Mar 2005, Paul Schlie wrote: > > 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 really have no idea what you're talking about here, and I don't see how you can call this 'recursive,' since your <block-comment> excludes the presence of the '#|' token entirely from its contents and certainly does not recursively refer back to <block-comment>. Block comments are furthermore still completely irrelevant to this SRFI. > <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. This is the crux of your argument, and it is wrong. A <datum> is built by a stream of tokens. Any token may be preceded by intertoken space, which is ignored. Since you have specified that <datum-comment> is considered a comment, which in turn is considered intertoken space, a <datum>, which begins with a token, may always be preceded by that token's intertoken space, which may be a <datum-comment>. Therefore: --- intertoken space --- (datum comment with B (from '#; A B')) / datum \ / vvvvvvvvvvvvvvv #; #; A B C <-- datum (token C, preceded by ^^^^\ intertoken space '#; #; A B') | \ datum (token A) \ intertoken space (datum comment with A) The unlabelled datum (unlabelled because it would severely complicate the presentation of that already somewhat complicated construction) is B, from the text '#; A B', which is the identifier token 'B' preceded by intertoken space '#; A'. (This all assumes that the translations from character streams to token streams & token streams to data are interleaved, which I've already pointed out is a bad idea in the context of R5RS's existing BNF.) > (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). Then these shall be the last messages on the subject.