Email list hosting service & mailing list manager

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 Taylor Campbell 24 Mar 2005 03:08 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.