Re: User defined precedence for user defined operators.

"Tommy Thorn" <tommy.thorn@gmail.com> writes:


> glen herrmannsfeldt wrote:
> > For new readers to this discussion, the question relates to being
> > able to specify the precedence for user defined operators (operator
> > overloading), and the possible ambiguities that can cause.
>
> It's a horrid idea, but it can be done. Fx. you could do it by
> completely ignoring operator precedence and reorder the tree at some
> point after parsing using the type information (this implies you'd
> have to keep parenthesis in the parse tree). Doing it on the fly is
> probably only possible with a hand-crafted parser.


If you only have a small number of possible precedences, you can use
different lexical symbols for each class and use a symbol table in the
lexer to decide the precedence class of a token. Precedence
declarations would update the symbol table.


> Notice, this is slightly similar to the problem with parsing C where
> (a) - (b) is ambigous and requires knowing if a is a type or a
> variable.


C is a lot worse, as it is not the declaration of the operators but
that of the operands that determine parsing.


Allowing unlimited declaration of new operators with different
precedence rules quickly make programs unreadable.


My own suggestion to solve this is to make the precedence be
determined by the name of the operator: You specify an initial set of
operators with a sensible hierarchy of precedence and associativity,
but make sure that operators that start with the same character have
the same precedence rules (different starting characters can share,
though, like + and -). One minor snag is that this does not allow
unary minus to use the same character as infix minus, but some
languages already make this distinction (SML, for example, uses ~ for
unary minus).


User-defined operators must start with a character from the predefined
set and automatically inherits the precedence rules of that operator.
So, if a programmer defines an operator +>, it automatically has the
precedence of +, while >* would have the precedence of >.


Once a programmer knows the standard operator set, he can immediately
see the precedence of new operators without having to find the
declaration. It also makes parsing simpler: The lexer can assign the
precedence class based on the first character, without having to use a
symbol table.


I wouldn't suggest to make the standard hierarchy too large, though.
Many programmers have trouble keeping track of the precedences of the
operators in C, so something smaller would be ideal. I wouldn't go a
far as Pascal, though, where AND and OR has the same priorites as *
and +.


                Torben

Return to the comp.compilers page.
Search the comp.compilers archives again.