new draft Taylor Campbell (27 Feb 2005 19:46 UTC)
Re: new draft Paul Schlie (28 Feb 2005 01:29 UTC)
Re: new draft Taylor Campbell (13 Mar 2005 20:44 UTC)
Re: new draft Paul Schlie (14 Mar 2005 07:46 UTC)

Re: new draft Taylor Campbell 13 Mar 2005 21:14 UTC

On Sun, 27 Feb 2005, Paul Schlie wrote:

> - the complexity is due to inconsistency of the lexical scoping specified
>   resulting in the necessary surgery to scheme's otherwise simple grammar;
>   which would not be necessary if the lexical scope of an <s-exp> comment
>   were arguably chosen to be consistent with the languages exiting grammar.

It requires 'surgery' to introduce S-expression comments to an already
overcomplicated grammar, which intermingles tokens in streams in a
vague and underspecified manner, the relation of which to EVAL's
argument is not very well defined.  This is not the traditional way to
define Lisp syntax, and the complexity of it in comparison to that of
recursive-descent parsers is evidence enough to show its clumsiness for
that purpose.

> > On the matter of nested comments: I am pretty firmly set on the current
> > way S-expression comments work.  Since it's an extremely specialized
> > case, since it has a very simple logical explanation, and since the
> > current way things work is a very simple addition to a traditional Lisp
> > recursive-descent S-expression parser, I'm inclined to stay with the
> > status quo unless the suggested alternative can be shown to be as
> > simple, in terms of logical explanation & recursive-descent parser, as
> > the status quo.
>
> - unfortunately not true, it's not consistent with scheme's grammar, nor
>   a consistent addition to a recursive decent parser, as it's doesn't have
>   a recursive lexical scoping semantics.

I don't understand what you mean here.  Perhaps you could elaborate.
That only a few lines are required to implement the current SRFI draft
in a simple recursive-descent parser clearly indicates that it most
certainly is consistent with the parser & Lisp's syntax.

> - more ideally would be to recognize that it may be easily be simply treated
>   just as quote, etc. is parsed, where (comment ... (quote ...)) is
>   equivalent to (quote ... (comment ...)), as such commenting any <s-exp> is
>   yields an <empty-s-exp>, just as quoting a commented (i.e. <empty-s-exp>)
>   also equivalently yields an <empty-s-exp>.

I don't even understand how you're suggesting that the construction
should be treated here, especially since you seem to be suggesting that
this SRFI add a new special form (COMMENT) that has strange semantics
when QUOTE sees it.  The current draft works very simply:

  When the S-expression reader meets the characters '#;', it reads the
  next complete S-expression, discards that, and reads the following
  S-expression.

> - for those so inclined, the following is a simple tweak of mzscheme's
>   reader, which does just this, and please note how it's both simpler, and
>   may actually prefer it's more consistent semantics:

An argument that some C code is simplified -- C code that seems to deal
with mostly shared structure, not so much S-expression comments -- with
your replacement S-expression comment syntax is not a convincing one.
If you want to make claims using code to assist your argument, please
do so with Scheme code, and please do so with comprehensible remarks
about the code.