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 Paul Schlie 24 Mar 2005 01:06 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-