Re: parsing with user defined operators

>Our esteemed moderator writes:
>> [It shouldn't be hard to concoct an operator precedence parser that can
>> do that, but I don't think it's a very good idea. User extensible syntax
>> was fashionable 20 years ago but now nobody bothers because it's so
>> phenomenally confusing. [...]]


[snip]
"Dr A. N. Walker" <Andrew.Walker@nottingham.ac.uk> writes:
> User-defined and overloaded operators are *incredibly*
>useful to certain classes of users. In mathematics, if we invent
>some new class of object, and if two of those objects can
>plausibly be added, then we naturally use the "+" symbol to
>denote the addition: "A := B*C + D", not


>[I agree that overloading can be very useful, but if you start inventing
>new syntax with unpredictable precedence, your programs become completely
>unreadable. (I speak from experience here.) C++ for example lets you
>overload with wild abandon, but the syntax is utterly unchangable. -John]


My master's project, Borneo
(http://www.cs.berkeley.edu/~darcy/Borneo), contains a proposal for
allowing user-defined operators while trying to prevent the program
from becoming confusing. Briefly, if a prefix of a user-defined
operator matches a built-in operator, the user-defined operator has
the same precedence and associativity as the corresponding built-in
operator. For example, "+^" and "+_" would both have the precedence
and associativity of "+". Therefore, the compiler and the programmer
can parse expression without having to perform type-checking or see
the operator declarations. There are some restrictions to prevent
syntactic mishaps; for example, the strings delimiting comments can't
appear in user-defined operators and user-defined operators can't have
a suffix matching the text of a unary operator (this prevents
whitespace from affecting how operators are tokenzied).


-Joe Darcy
darcy@cs.berkeley.edu

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