Re: Comments on parsing steps:

>Thanks for your patience in examining this issue.

There are lots of subtle issues to get the grammar to work right.
These grammars are beyond simple operator precedence parsers.
Since I've done one implementation, I feel I have some knowledge of
pitfalls.  I think prefix embellishments are trouble...

>
>> Are you saying that '&bold' will always grab the *token* to the right,
>> independent of what a parser might normally do?
>
>This would be an easy thing to explain and to learn.

Except it probably isn't true.  Eg, what about '&bold &big x'.
This would change the rule to be "it grabs the token to the right,
unless the token on the right is a (prefix?) embellishing operator,
in which case....".

My guess is that for any non-parser based solution you adopt, I can come
up with something that messes it up.

>
>> People may or may not understand about prefix, infix, etc., operators,
>> and they certainly won't look up relative precedences in a dictionary unless
>> they are really desparate.  Embellishing operators are another detail
>> that people probably don't want to know.
>
>I disagree. For a limited set of embellishments, such as for altering
>the presentation or adding an accent, it looks like a useful capability.
>
>> If we have prefix embellishing operators such as &bold, I don't think
>> people would understand why '&bold + 2' parses to (I claim) '&bold {+ 2}'.
>> I'm interested to see your algorithm to make them behave in a more intuitive
>> way, but am dubious that it can be done without great complication to the
>> parser.
>
>"bind to the next token" works well. {&bold +} acts like `+' so that
>adjacent tokens bind as expected. This depends on &bold being restricted
>to a single role as a prefix embellishment operator. This requires a
>simple check on the patterns [Op1 Op2|T] and [L Op1 Op2|T]
>
>If say it could also act as a normal prefix then the this role would
>only apply when the next token to the right is not an operator.
>This sounds like it is going to be a little too subtle for most people.

Although I am always in favor in coming up with a design that allows
people to type the intuitive thing in, I am much more in favor of something
that can be described on paper in a fairly clean manner.  This makes
different implementation more likely to implement the same language
and allows for readers to figure out what they should do, when something
doesn't work the way they expect.  When clean description and intuitive
use both exist, you know you have a winning design.

If people really feel strongly that prefix embellishments should be allowed,
I think that we should just tell people that if they embellish an operator,
they should use braces to force the desired grouping.  Otherwise, I think
that they will have to know more about parsing than anybody should have to
know.

	Neil