[ ... ]
It's not ambiguous if you're a C compiler, but it is if you're a human who
hasn't memorised all the operator precedence rules.
Based on this reply, about all I can guess is that you don't know what
"ambiguous" really means.
Ambiguous means I have to look up a bunch of hidden rules that were
added to an ambiguous language and arbitrarily resolve the parsing
conflicts. The existence of the hidden rules doesn't solve all of the
problems.
By the way, look at the ridiculous grammar factoring that's needed in
order to avoid the use of explicit precedence and associativity rules.
The expression 42 ends up being a multiplicative-expression *and*
an additive-expression at the same time. Yet it neither adds nor
multiplies.
Being ignorant of the meaning of a statement
doesn't imply that the statement is ambiguous; to be ambiguous, it
must be impossible to determine the meaning of the statement,
regardless of one's knowledge of the language, etc.
My utter ignorance of Japanese is FAR from justification for claiming
that all Japanese is ambigous.
I'm almost certain that Japanese is full of ambiguities, being a
natural language.
The difference is that there aren't any hidden rules about it. An
ambiguity in natural language doesn't pretend to be something else.
If you utter something ambiguous that leads to a misunderstanding, you
can't claim superiority by referring the poor victim of your
misunderstanding to an associative precedence chart.
Now every message must have some hidden rules which indicate how it
should be parsed. But those rules can be made minimal. Moreover, the
message can even be structured such that the rules can be just about
deduced from its structure.
An ambiguous message is one whose parsing cannot be cracked without
access to the hidden rules, even if it is encountered by an
intelligence which is able to correctly figure out every other aspect
of the message, like which symbols are operators and operands, and
that the operators are binary, and so on.
Suppose that an alien encounters a message from Earth which looks like
A + B * C / D - E * F
The alien might be able to deduce what the operators are, and then it
is stuck.
Now the same alien receives:
(- (+ A (/ (* B C) D)) (* E F))
Aha, it's obvious that the two symbols ( ) are special and that they
serve to enclose, as suggested by their shape. Moreover, they balance,
which reinforces that suspicion.
Given a larger repertoire of such messages, it becomes obvious that
the operators like * and + always appear in the left position of a
sublist, and the other symbols like A B C are in the remaining
positions. So the message itself can convey the idea that + - * / are
somehow different from these other A B C ... In the first message,
even this is huge leap. One could suspect that A and + are unary
operators, and find nothing in the message to contradict the idea.
I find it particularly interesting that C and C++ both contain some
things that (based on pure syntax) really ARE ambiguous, but those
What, like evaluation orders? That's not pure syntax, but semantics.
That's a whole different pile of unbelieveable idiocy that should have
been fixed long ago.
Or, I'm guessing that perhaps by ``pure syntax'' you mean ``just the
raw grammar, with no symbol table information''. As in, what is this:
(a)(b)(c)+(d);
Our choices are:
typedef int a, b, c;
int d;
// ...
(a)(b)(c)+(d); // unary + expression put through casts!
Another choice:
extern int (*a(int))(int);
int b, c, d;
// ...
// call a with argument b, which returns pointer to a function that
// takes int and returns a pointer to an int -> int function.
// This function is called with argument c. The result is added
// with the value of d.
(a)(b)(c)+(d);
And so on. I once wrote a parser which could deal with these
ambiguities. The goal of the parser was to classify an expression into
three categories: 1) has side effects for sure. 2) might have side
effects depending on which way it is parsed and 3) has no side
effects, for sure. When there was an ambiguity like the above, it
would parse it both ways, record its findings and backtrack. The
backtracking was done using an exception handling package hacked over
setjmp and longjmp in C.
With this package, one can put assertions into function #define
macros, so that at run time, suspicious uses of these macros would
blow up!
For example, suppose you were implementing a macro for int getc(FILE
*) macro, and you needed to evaluate the stream variable twice in the
macro expansion.
With my package, I could write the getc() macro call such that when
the first time it is evaluated, the enclosed expression is parsed and
classified. If it is found to have side effects, like getc(stream++)
then the program stops with an assertion. If it's suspected to have
side effects, a warning is produced and the program continues, and of
course if there are no side effects, it is silent. In both these
cases, the expression is stored into a hash table so it doesn't have
to be parsed again; the next time that same call is evaluated, the
hash will tell that all is good.
So as you can see, I have done some incredibly devilish things in
order to make a dumb language safer.
