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)
|
On Tue, 22 Mar 2005, 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. (Your block comments are also inconsistent with SRFI 30, by the way, but that is not relevant to this SRFI.) > (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. 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.