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 23 Mar 2005 03:35 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.