Re: parsing with user defined operators

"Dr A. N. Walker" <>
27 Aug 1999 01:48:47 -0400

          From comp.compilers

Related articles
parsing with user defined operators (1999-08-12)
Re: parsing with user defined operators (Torben Mogensen) (1999-08-13)
Re: parsing with user defined operators (1999-08-15)
Re: parsing with user defined operators (Dr A. N. Walker) (1999-08-27)
Re: parsing with user defined operators (rspartan) (1999-08-27)
Re: parsing with user defined operators darcy@moa.CS.Berkeley.EDU (1999-08-28)
| List of all articles for this month |

From: "Dr A. N. Walker" <>
Newsgroups: comp.compilers
Date: 27 Aug 1999 01:48:47 -0400
Organization: School of Mathematical Sciences, University of Nottingham, UK.
References: 99-08-053
Keywords: syntax, design, comment

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. [...]]

Well, whether user-defined operators are extensions to
the syntax or to the semantics is a matter of semantics ....
Use of a pre-processor is also *potentially* phenomenally
confusing, and arguably not a very good idea, but no-one is
seriously suggesting that C programmers should manage without

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

matrixassign (A, matrixadd (matrixmult (B, C), D))

[or "graphassign ...", "vectorassign ...", "operatorassign ...",
"functionalassign ...", etc through dozens of classes]. Equally,
if I invent some new binary operator, then in a paper I'm likely
to use it infixed, not as a function name, and it's very nice if
related programs can do likewise.

There is no *huge* difficulty in compiling new operator
symbols and overladen old symbols, and there is no loss of
efficiency [as they are, in the end, just the same as the
function calls they replace]. They are part of the syntactic/
semantic sugar that used to make Algol 68 so much more pleasant
a language for intelligent users to write in than any of its
rivals or successors, and I, for one, miss them.
Andy Walker, School of MathSci., Univ. of Nott'm, UK.
[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]

Post a followup to this message

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