Re: User definable operators

Ehud Lamm <mslamm@pluto.mscc.huji.ac.il>
15 Dec 1996 16:17:16 -0500

          From comp.compilers

Related articles
User definable operators wclodius@lanl.gov (William Clodius) (1996-12-14)
Re: User definable operators fjh@murlibobo.cs.mu.OZ.AU (1996-12-15)
Re: User definable operators cef@geodesic.com (Charles Fiterman) (1996-12-15)
Re: User definable operators mslamm@pluto.mscc.huji.ac.il (Ehud Lamm) (1996-12-15)
Re: User definable operators ddean@CS.Princeton.EDU (1996-12-15)
Re: User definable operators dennis@netcom.com (1996-12-15)
Re: User definable operators fjh@mundook.cs.mu.OZ.AU (1996-12-15)
Re: User definable operators burley@gnu.ai.mit.edu (Craig Burley) (1996-12-18)
Re: User definable operators jdean@puma.pa.dec.com (1996-12-18)
Re: User definable operators neitzel@gaertner.de (1996-12-18)
[16 later articles]
| List of all articles for this month |

From: Ehud Lamm <mslamm@pluto.mscc.huji.ac.il>
Newsgroups: comp.compilers
Date: 15 Dec 1996 16:17:16 -0500
Organization: The hebrew University of Jerusalem
References: 96-12-088
Keywords: design

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
--


Post a followup to this message

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