> [snip] > What you're left with is the sequence in which you must compute your > operations. So, for example, > > (3+4)*(5*(6+7)) > [snip] > So, what we have to do is to compute in precedence order, > > 6+7=13 because the rightmost + has precedence 22 > 5*13=65 because the rightmost * has precedence 12 > 3+4=7 because the leftmost + has precedence 11 > 7 * 65 = 455 because the leftmost * has precedence 2. > > The point that these rules of precedence get operations [to] behave as > if a distributive law holds is of second importance here,
Nowhere in the above does the distribute law make an appearance. Your rules of precedence will not imply the distributive law.
The rules of precendence are equivalent to an algorithm to translate infix notation into either prefix or postfix notation (the two being obviously equivalent) and back again.
> parsing the > expression using the distributive property
Distributivity is not a property of an expression.
> is a waste of time for both men and machines.
On the contrary, it is invaluable for computational purposes. (Look up Horner's rule, for example.)
> Now, change the precedences, and guess what ? The meaning of the > expression may change. That's why something like > a + b*c + d > is ambiguous, notationwise, unless we apply operator precedence rules > to it.
That's why we have operator precedence rules.
> These precedence rules can be contrived to satisfy the > arithmetic distributive property;
Again, distributivity has nothing to do with notation or precedence rules.
Distributivity, in your favourite postfix notation, is a b c + * = a b * a c * + . It is a property of the + and * functions.
> And in modern computing, we are entitled to > overload the meanings of scribbles such as "+" and "*" to mean things > other than numeric addition and multiplication,
Yes, and the parser will still work, because it does not have anything to do with distributivity. The optimizer won't work, though (so the compiler won't call it to optimize expressions involving overloaded operators [unless there is a way to tell it how to optimize them]).
> so in a way the > traditional math track is a bit stifling here, we need to have rules > to parse expressions that work at syntatic level only and pay no > attention to the semantics of the underlying operations. I said it > before, the advent of computers has put a different spice into this > brew.
The order of operations in use today predates computers by at least hundreds of years.