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 23 Mar 2005 17:00 UTC

> From: Taylor Campbell <xxxxxx@bloodandcoffee.net>
>> Paul Schlie wrote:
>> In hopes it may be helpful, the following is a somewhat simpler version of
>> an earlier one: http://srfi.schemers.org/srfi-62/mail-archive/msg00045.html
>> which only modifies R5RS's definition of <comment> (effectively treated as
>> separator/white-space); which includes <block-comment>, and removes legally
>> quoting and/or commenting, a comment or <empty>:
>>
>> Only modifying one R5RS's exiting grammar specification:
>>
>>    <comment> -> <line-comment> | <block-comment> | <datum-comment>
>>
>> And augmented it with these additions:
>>
>>   <line-comment> -> ; <all-chars-to-end-of-line>
>>
>>   <block-comment> -> #| <all-char-except-#|-or-|#> |#
>>
>>   <datum-comment> -> #; <datum>
>>
> One problem with this is that it creates mutual references between
> sections 7.1.1, which describes the lexical structure, and 7.1.2, which
> describes the external representation of S-expressions -- in terms of a
> stream of tokens.  While I find the 'stream of tokens' model very
> distasteful to describe Lisp syntax, it is nevertheless how the current
> framework for Scheme's syntax works, and breaking it is not a good idea
> -- especially since you seem opposed to such massive changes anyway, or
> at least that was the impression I got from your previous objections.

- I'm honestly confused, the above representation is fully consistent with
  R5RS and your own alternative referenced specification of scheme grammar,
  (your proposal isn't with either, as it doesn't properly classify "#;
  <datum>" grammatically as a comment, which it is both syntactically and
  semantically inconsistent, with it needs to be parsed as <whitespace>. I
  apparently need to be more explicit, given it's effective specification:

  <whitespace> -> [ <whitespace-character> | <comment> ] <whitespace>

 (which is the grammatical vehicle used to denote that comments are ignored)

> (Your block comments are also inconsistent with SRFI 30, by the way,
> but that is not relevant to this SRFI.)

- how? other than being simpler, it seems fully consistent with it's text?

>> (i.e. #;#; '#; (#;) (') etc. are illegal sequences, vs. earlier versions.)
>
> Actually, with the way you just presented it, immediately nested
> S-expression comments work exactly as in the current proposal.

- Almost, as I intentionally simplified it stating: "and removes legally
  quoting and/or commenting, a comment or <empty>", as it seemed to be
  confusing an otherwise very simple specification. (but note your following
  semantic interpretation is not consistent with it, i.e. wrong.):

>                                                                 First,
> consider the text '#; A B'.  If parsed as a datum, the value will be
> just B, since the '#; A' is considered intertoken space.  (This follows
> straightforwardly since A is a datum, and so the text '#; A' satisfies
> your <datum-comment> rule.)  So the whole of '#; A B' is one datum (as
> defined in R5RS section 7.1.2).  If we then attempt to parse '#; #; A B
> C' as a datum, we see that there is some intertoken space first, namely
> #; followed by a single datum.  Since we determined that the text '#; A
> B' qualifies as one datum, '#; #; A B' must be one datum comment, and
> the only item remaining in the input stream is C.  Thus '#; #; A B C'
> reads as the symbol C.

- candidly haven't a clue of how you believe a recursive parser parses the
  above grammar, but it simply specifies that: (given <ws> :: <whitespace>)

  "#; #; A B C" :: "<error> <ws> <A> <ws> <B> <ws> <C>"

  (as the grammar only specifies a legal parsing of "<#;> <datum>" as a
   <comment> => <whitespace>, therefore "#; #;" is not a valid sequence,
   as <#;> may not validly begin a <datum>, therefore a parse error.)

  If you want to give "#; #; A B C" a consistent meaning, here are your
  grammar specification options: (in addition to the one above):

  1 - <datum-comment> -> #; [ <datum> | <datum-comment> ]

       Which specifies "#; #; A B C" :: "<ws> B <ws> C", as:

       "#; #; A" => <ws>{<datum-comment>{#; <datum-comment>{#; <datum>}}}

  2 - as I denoted 2 months ago, which also further specifies the meanings:

       [` | ` | , | ,@ ] [<datum-comment> | <empty>]

  The reason you're having difficulty trying to cleanly specify:

   " The first datum within a commented datum is ignored, as is any datum
     immediately following the "#;" token in a delimiter prefix. "

   is that it's a lousy inconsistent semantic behavior to try to specify,
   vs. one more consistent with the language and recursive decent grammars:

  " The <datum-comment> specified as a <#;> followed by a <datum> are
    ignored as <whitespace> "

  -or-

  " The <datum-comment> specified as a <#;> followed by a <datum> or another
    <datum-comment> are ignored as <whitespace> "

  -or-

  " The <datum-comment> specified as a <#;> followed by a <datum> or another
    <datum-comment> or <empty> are ignored as <whitespace> "

  -or-

  " The <datum-comment> specified as a <#;> followed by a <datum> or another
    <datum-comment> or <empty>; or a quoted <datum-comment> or <empty>; are
    ignored as <whitespace> "