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> >> 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. - yes, I apologize, you are correct; it should have been denoted: <block-comment> -> #| <any-char-or-block-comment>* |# <any-char-or-block-comment> -> <any-char-ex-#|-|#> | <block-comment> >> <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) - Sorry, in a nutshell, I don't believe a left recursive grammar is consistent with scheme's existing exclusively right recursive grammar; and candidly still surprised anyone would, but what you advocate is: <datum-comment> -> #; <datum-comment*-datum> <datum-comment*-datum> -> <datum-comment>* <datum> ; left recursive "#; #; A B C" => "{datum-comment {datum-comment A} B} C" => "C" -vs- <datum-comment> -> #; <datum-or-datum-comment> <datum-or-datum-comment> -> <datum> | <datum-comment> ; right recursive "#; #; A B C" => "{datum-comment {datum-comment A}} B C" => "B C" (as "' ' A B C" => "(quote (quote A)) B C", not "(quote (quote A) B) C")