This page is part of the web mail archives of SRFI 105 from before July 7th, 2015. The new archives for SRFI 105 contain all messages, not just those from before July 7th, 2015.
Mark H Weaver: > The current draft says: > > 5. An unprefixed ( . e) MUST evaluate as e. > > s/MUST evaluate as/MUST be read as/ I agree that the word "evaluate" here is misleading, so yes, we should fix that to clarify things. However, the rest of the text uses "maps to" or its abbreviation =>. So for consistency with the rest of the text, it should probably instead say something like this: .... 5. An unprefixed ( . e) MUST map to e. > I've attached a patch which fixes this, and also improves the HTML > markup. Most notably, I converted many VAR elements to CODE elements, > e.g. every occurrence of $nfx$ and $bracket-apply$, since these are not > variables for purposes of this specification, but rather constant > symbols. > > I used VAR for symbols that can stand for any of a set of expressions > (e.g. 'e', 'e1', and 'e2' in the n-expression spec), which I believe is > a more appropriate use of VAR. I also tried to use CODE and SAMP where > appropriate, and avoided marking ellipses with either one. > > What do you think? I think you're right, that's a more accurate use of HTML tags & it produces more consistent typography. It's subtle but nice. Whew, that was a lot of work, thanks for doing that. I propose accepting the HTML tagging, and changing the line about unprefixed (. e) to use the term "map" like everything else does. Any other last-minute comments? --- David A. Wheeler