Re: User definable operators

The idea of allowing the user to define operatores is quite ecxiting
and promising in theory... In practice life is not a garden of
roses. There are several problems, I heard of when studying this
problem.


1. Since operators assoc. and precedence define the way you parse the
language, parsing becomes much more difficult. This should slow down
parsing, and make the parsing algorithm used much harder. This is the
reason, I think, many languages allow you to redefine EXISTING
operators without changing thier properties - just their
functionallity. This can be solved by parsing expressions with an
operator precedence table driven parser. Most languages are not parsed
like this when it is not needed.


2. The extension part of the language is usually not an integral part
of the language itself. It is mostly glue stuff, used to define to the
parser what to do. (Look at things like opsyn in Prolog). This tends
to cause the language to lose simplicity and makes it inelegant.


3. Programs with user defined operators are harder to read and
maintain - since each piece of code is written in its own dialect.


4. If the language is not Object Oriented you are likely to have
problems when two pieces of code with different operators "meet".


5. Questions like how to specify precedence (how many levels of
precedence should you use), how to handle associativity (which is a
bit harder then merely operator precedence if I recall correctly) are
the next step.


I'd be happy to hear how you solve all this. I find the *idea* of
extensible languages fasciniating. The practice in the field shows
many problems though.


I'd also take a look, if I were you, at Prolog (with opsyn), Scheme
(with hygenic macros - which are not operators but are an interesting
way to allow extending the language without breaking it), and of
course APL (which doesn't have any of these problems, since it lacks
precedence and associativity).


  Ehud Lamm mslamm@pluto.mscc.huji.ac.il
--

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