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