This page is part of the web mail archives of SRFI 107 from before July 7th, 2015. The new archives for SRFI 107 contain all messages, not just those from before July 7th, 2015.
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 cowan@xxxxxxxx and man and metre.