Re: Progress on Parsing

> To make it work, users would
> have to bracket the integral expression, e.g.
> 
>      y = 1 + {integral of sin(x) wrt x} * cos(x)
> 
> I find this unacceptable ....

Personally, I find this acceptable. Note that, if we do find some way
(whether by a separate template-parsing step, or by precedences) to
make

	y = 1 + integral of sin(x) wrt x * cos(x)

bind the way you want, new users trying to figure out how it works
will probably be confused.

---

> The final tokenizer will function correctly with '\' before tokens
> so that a LaTeX like notation can be expressed by people who don't
> like the above style of tokens.

I favor making it possible for authors to use whatever form they
want; but this doesn't remove from us the responsibility to decide
the form which will be used by the default macros supplied by the
standard, which we must design as carefully as if they could not
be overridden, since many people will want to use them, partly
since they will carry standard semantic connotations which
author-defined macros won't (unless they transform into our own
macros as an intermediate step).

For the same reasons as expressed above on the other issue, I'm
now sure that I don't support any operators which look like
identifiers as part of the standard (default) set of macros. I
think that

	y = 1 + {\integral \of sin(x) \wrt x} * cos(x)

is acceptable enough to be well worth the reduced confusion to new
users trying to understand what's an operator and how things bind.

This doesn't mean I disagree with allowing author-defined macros
which let "y = 1 + integral of sin(x) wrt x * cos(x)" work -- in fact
I favor having author-defined macros be as powerful as possible.

Note also that nothing prevents a particular WYSIWYG expression editor
from allowing you to edit HTML-Math in a source-text form but without
having to see or type the \s preceding certain operators.