On Wed, 23 Mar 2005, Paul Schlie wrote:

> Ok, now I understand the problem, you're trying to justify a refinement
> of scheme's grammar based upon the limited facilities available within
> scheme48 at the user level, rather than refine it's parser code.

This is absolutely ludicrous and absurdly derogatory of how Lisp
readers do and always have worked.  First, this is _NOT_ something
specific to Scheme48.  Though that is one of my favoured Schemes, it
has no intrinsic relation to this proposal.*  I used Scheme48's reader
because it is a simple recursive-descent parser that is representative
of the simplicity of S-expression-based syntax & recursive-descent
parsers, and that was easy to extend.  You have demonstrated that you
have clearly given _no_ consideration to how such Lisp readers work.  I
moreover have no idea why you invent this imaginary distinction between
a 'user level' and 'parser code'; the code I attached to the SRFI 62
document _is_ Scheme48's parser (augmented with S-expression comments).

I shall no longer consider your alternative, anti-Lisp proposal, and I
have no further intention of wasting time arguing over this point.  I
have presented a single, complete, & simple formal specification, as
well as a simple informal specification, for how my proposal works; I
have shown that it meshes well with the recursive-descent parsers by
which Lisp's syntax has traditionally been defined.  You, however, have
done neither of the two, and you have not even presented your preferred
proposal coherently or consistently enough for me to even understand
exactly what it is you're trying to suggest, beyond the fact that it is
clearly geared towards unwieldly tools like BNF in languages with much
too complicated syntax and against Lisp recursive-descent parsers.

* _All_ of the Scheme systems I tested (of those that already support
S-expression comments) already handle the nesting case that you object
to in the exact same way that the current proposal does.