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 01:49 UTC

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>

(i.e. #;#; '#; (#;) (') etc. are illegal sequences, vs. earlier versions.)

> From: Taylor Campbell <xxxxxx@bloodandcoffee.net>
> I recently wrote an alternative specification of Scheme's syntax using
> (roughly) BNF, but in such a way that is much more in the spirit of
> Lisp: the syntax of the external representation of S-expressions is
> separated from the syntax of Scheme, and S-expressions are specified in
> such a way as to resemble a recursive-descent parser as closely as
> possible.  That is not the point of this message, though.  In writing
> the alternative specification, I realized that S-expression comments
> can be specified much more simply.  Specifically, all it requires is
> that the <datum>, <list>, & <vector> non-terminals be extended, and a
> <commented datum> be introduced.  (<Token> must of course be extended
> with a "#;" option, too.)  <Datum> becomes:
>
>   <datum> ---> <simple datum> | <compound datum> | <commented datum>
>   <commented datum> ---> "#;" <datum> <datum>
>
> <List> & <vector> use a couple of auxiliary rules; they are all
> presented here:
>
>   <list> ---> "(" <datum>* <optional dot> <delimiter prefix> ")"
>   <optional dot> ---> <empty> | <datum> <delimiter prefix> "." <datum>
>   <vector> ---> "#(" <datum>* <delimiter prefix> ")"
>   <delimiter prefix> ---> <empty> | "#;" <datum> <delimiter prefix>
>
> The first datum within a commented datum is ignored, as is any datum
> immediately following the "#;" token in a delimiter prefix.
>
> This formal specification is much simpler than what Al* Petrofsky
> suggested earlier, and I think it should satisfy Paul Schlie's demands
> for a grammar more consistent with Scheme's existing one.  If no one
> sees any problems with it, I'll change the SRFI document to use it and
> finalize the SRFI, which is a bit overdue.
>
> Should Paul Schlie still prefer his own specification, which I still
> don't understand, he should provide an implementation of it in terms of
> Scheme48's reader (as I show in the document), and he should explain
> why he wants to so drastically change the various reader abbreviations,
> those for QUOTE, QUASIQUOTE, &c., to magically disappear due to their
> being in what was previously syntactically invalid locations.
>
> (My alternative specification of Scheme's syntax, by the way, is at
> <http://www.bloodandcoffee.net/campbell/code/scm-syntax.text>, for
> those curious.  Any comments, questions, or other feedback on it would
> be appreciated, though such feedback should be sent to me directly, not
> to this mailing list.)
>