C
Charlie Gordon
Keith Thompson said:
I was expecting this. It was my first reaction too.
It is required for the sake of compatibility with current semantics of
binary * and unary *.
I like the way tokenization works too. But extending the grammar without
clashes with the current semantics sometimes requires "contorted" ways.
There already are uncanny side effects with the unary * operator: `` x/*p''
does not parse like ''x / *p'' ;-). Javascript extended its C-like syntax
roots to include support for regular expression literals: support for the
/regex/ syntax requires feedback from the grammar into the lexer, but the
programmers need not be aware of this.
Operator overloading in C++ does not allow redefining operations on scalar
types. It would be acceptable to restrain ** to operate only on types for
which x * (*p) does not have a meaning already.
What would be more surprising and make this idea unworkable is the bizarre
precedence it gives the fake ** operator: ``a*b**c'' would parse and
evaluate as ``(a * b) * (*c)'' effectively making ** less binding than *
(counter-intuitive), but ``a**b*c'' would parse and evaluate as ``(a * (*b))
* c'' making ** more binding than * in this case.
A more consistent proposal is to allow creating new custom operators and
tokens, with specified precedence and associativity, but no built-in
support. This way you keep compatibility with existing code that does not
make use of these 'extended' operators, and give proper support for
extending the syntax and grammar in a consistent and intuitive way. You
need a specific syntax for defining the new operators, preferably at the
preprocessing level:
#operator ** binary left 2.5 /* new token **, binary operator, left
associative, binds more than * / % */
double operator ** (double x, double y) { return fexp(x, y); }