But we are talking about operators for 2 different data types.

If one writes:

" " x $indent*$spaces_p_tab . 2+3 ." + " . 4+6 . " == ".3*5
[download]

Since if you do the string operations first or give them equal precedence with the number operations, you end up with an invalid result. Why not do the evaluation that naturally gives you a valid result rather than choosing a rule to make it wrong?

I would say that humans tend to group like with like and that a well designed parser would follow that premise over one that makes humans wrong.

Wouldn't it make sense to do the number operations first then combine their string representations with the strings?

If that's the only type of compound expression anyone ever writes which mixes string operations with numeric operations, perhaps. Unfortunately, it's not. Thus the possibilities are 1) to add even more precedence levels to add special cases things like the repetition operator, 2) to require disambiguating parentheses where the default precedence levels are wrong for special cases like this, or 3) to enforce a strict left to right evaluation order.

I would say that humans tend to group like with like and that a well designed parser would follow that premise over one that makes humans wrong.

You're poisoning the well.

Among your possibilities... (2) AND (3) are required. There is a strict left to right evaluation among {x*/} and {.+=}, AND parenthesis are required in simple expressions. Adding the precedence levels described would eliminate default precedence levels being wrong (because in this case there is no right way to create the expression without them), and would allow strict left to right evaluation within the same types.

In an expression like:

' ' x 2*3
[download]

it is more efficient for the interpreter to do the numeric calculation first as 2*2 is 1 instruction while the other requires buffer allocation for a result. So perl has to do MORE work -- to end up with an expression that fails. If that's not a hint that the precedence rules could use some fine tuning, I don't know hat is.

Currently, the operators, 'x', '*', '/' are at the same level. Below them are '.', '+', and '-'.

But having the string operators at the same level as the numeric operators doesn't makes sense. If there is a logic in that choice, please explain it. In mathematics it is generally a given that an simple expression can be simplified by distributing operands and getting rid of parentheses.

'x' doesn't belong in the same group as * and /. One, because it isn't communicative, 2) because technically it's a call to an internal API-function that requires its arguments in a specific order. It's even more rigorous in its requirements than ".".

This is a case of the language breaking the principle of generalization. The only way you can intermix those operators is if all operands are numbers and then you end up with a very specialized usage that isn't intuitive at all.

I'm proposing the idea that in separating the precedence, we make the ability to combine statements composed of numbers and strings a generalized possibility, whereas now, it's a special case in the language -- more so because the 'x' operator isn't commutative.

As for your common on poisoning the well, I am not sure I follow, unless you mean by my persistence, in adherence to ideals I alienate people. That is unfortunate if that is the case.