Email list hosting service & mailing list manager

Slimming down SRFI 107 John Cowan (18 Nov 2012 19:22 UTC)
Re: Slimming down SRFI 107 Per Bothner (18 Nov 2012 19:54 UTC)
Re: Slimming down SRFI 107 John Cowan (18 Nov 2012 20:28 UTC)

Slimming down SRFI 107 John Cowan 18 Nov 2012 19:22 UTC

I have read SRFI 107 in between working on R7RS-small, and I am very glad
to see a proposal like this.  However, I think there are very serious
intelligibility problems with the current draft that will require
wholesale reorganization and the sacrifice of certain portions (some
of which may be resurrected in a future SRFI).  I also have a number of
substantive comments, and I'll probably have more when a new cleaned-up
draft is issued -- I'll put these in a separate email.

The Rationale says: "This specification defines a Scheme reader extension
matching XML syntax with expression escapes (unquote), a translation into
standard S-expressions, and a semantics for the latter."  In my opinion,
the third goal is met only in part, and it should be removed altogether,
leaving only the lexical syntax of the extension and its translation into
S-expressions.  This would greatly simplify and clarify the discussion.

In particular, the paragraph beginning "When evaluating the expression
(in the first variant), the result is a QName value" should be recast
into an explanation not of what QName values are, but the statement that
names with colons are mapped into lists.  The translation section then
specifies the exact format of these lists.

It's not clear to me at present whether the translations should be
interleaved with the lexical syntax descriptions or put off to a later
section as the current draft does.  My intuition says the first plan
will be clearer, but I can't say for sure.

Almost all of the "Handling of enclosed expressions" section should
go away, because it depends on what the macros/procedures do.  This is
the core of the (very partial) semantics, which I strongly believe this
SRFI should not prescribe.  For example, whether evaluation of enclosed
expressions is done at runtime or not depends on whether the macro puts
them into an evaluable position or not, as does the treatment of numbers
as strings, and so on.

Similarly, the "Translated forms" section should mostly go away or be

I think that if all this can be done the SRFI will become much more
accessible, useful, and potentially more portable, since it will serve
more easily as a facade over existing representations of XML.
reformulated so that it does not depend on what the macros/functions do.

--
Here lies the Christian,                        John Cowan
        judge, and poet Peter,                  http://www.ccil.org/~cowan
Who broke the laws of God                       xxxxxx@ccil.org
        and man and metre.