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)

Re: new, simpler formal specification Paul Schlie 24 Mar 2005 05:37 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")