Re: Comments on parsing steps:

>I am unconvinced by your examples.
>
>> When the parser encounters something like a + _2 b,
>> it knows by the time of reading the '+' that it must have a right operand.
>
>Fine, but that also applies to:
>
>        a &big + b
>
>with the information that &big can act as a prefix embellishment operator
>this yields:
>
>        {a {&big +} b}
>
>Otherwise this would parse as:
>
>        {a . {&big {+ b}}}
>
>where `.' is an inferred infix operator, presumably denoting multiplication.

How far ahead are you proposing the parser look in order to avoid inserting
an operator?  Almost every computer language uses one token look ahead.
Making the above work requires more than one token lookahead.

>
>> However, consider the following:
>
>>       &bold + 2
>
>> with '&bold' being a high-precedence prefix operator. When the parser sees
>> the '+', it sees that it must be a prefix operator, and so will shift the
>> `2' on.  So, this expression would result in:
>
>>       {&bold {+ 2}}
>
>If each operator has a property indicating that it can act as an
>embellishment on other operators, then we can use this fact to make

embellisment is not specific to just operators.  Eg: 'a_2' or '&bold a'

>the above parse as
>
>        {&bold +} 2
>
>in preference to the interpretation of &bold as a normal prefix operator.
>In essence we sort the operator precedence reduction rules into a sequence
>that resolves potential ambiguities between different operator roles defined
>by the dictionary for each symbol.

Please explain the exact rules you have in mind for embelling operators.
If a parser sees '&bold + 2', where '+' can be a prefix operator, no precedence
ordering will produce '{&bold +} 2'.
Are saying that '&bold' will always grab the *token* to the right,
independent of what a parser might normally do?

>
>You have already asserted that people are comfortable with dictionary
>definitions for the roles of symbols as prefix, infix or postfix operators
>(including their precedences). Extending the dictionary to define whether
>each symbol can act as prefix, infix or postfix embellishment operators
>seems a straightforward addition.
>
>Can you give me examples that would be hard to explain to a user?

I think people are comfortable with a language that works the 
way they think it should work.  People know what "2a+b/c" parses to ("means").
They are probably also comfortable with less familar notations such as
"a < b & b < c &implies a < c" -- I doubt people consciously think about
the relative ordering or types of '<', '&', and '&implies' -- they just
expect it to work "right".  It is our job to make sure the precedences
are set up correctly.  When things get really hairy, people will start
forcing groupings, for both their (sanity's) sake and for correct parsing.

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 know.
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.

My feeling is that if we want to introduce prefix embelling operators,
then we should tell people they should explicitly group them with their
operatand to avoid confusion.

	Neil