|
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>
>> 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> "