> Linda W wrote:
>> But it CAN'T why isn't it like the REGEX parser -- if it is obvious that
>> parsing it with = higher, won't work, why not parse it the way it
>> would work?
> Consistency. Switching operator precedence based on semantic requirements
> would get very confusing.
Scratch operator precedence, strictly consider legal interpretations.
I.e. As you mentioned, I could use parens (I use the ('if' construct in my
original code, so they are already there ;-)).
However, generally, parens are required when you need to override
operator precedence to override 'defaults', that (like precedence), that
if NOT there,
would lead to ambiguity.
In this instance, there can be no ambiguity, as interpreting the
= as higher precedence, leads to a syntax error -- thus there is no
'guessing' -- it should never have tried to parse the statement
illegally but defaulted to the only legal interpretation.
I.e. rather than having defaults that *create errors*, why not have
defaults that produce working code? With the use of the ternary
operator, it is known in advance that there will be 3 expressions. It
makes no sense to interpret ambiguous situations to the deficit of the
user. The only sense where one would want to increase user errors, is if
you are a sadist or needing to scrutinize for security (is there a
What I would propose is that the default to die w/errors be
override-able with a
use default_to_workable, vs. the current default which seems to prefer
errors over working code if there is any ambiguity.
It would be purely *optional*... i.e. not a default, but usable by
anyone in their code.
Does that sound more reasonable? Would it be a major pain with the