From: | rrogers@cs.washington.edu (Richard Rogers) |
Newsgroups: | comp.compilers,comp.lang.misc,comp.arch.arithmetic |
Date: | 13 Mar 1997 23:45:16 -0500 |
Organization: | Computer Science & Engineering, U of Washington, Seattle |
References: | 97-03-037 |
Keywords: | design |
Do you think the definable operators make things worse than, say,
poorly chosen identifiers? It seems to me that the risks to code
quality from allowing definable operators are about the same, but the
potential benefits are quite large. While I certainly would not
advocate allowing arbitraty syntax definition, I have been toying with
the idea of providing a large set of operators (~ those available in
TeX or FrameMaker's equation editor) which could be overloaded
appropriately. How frightened does that make you? :-)
In fact, I might go as far as to say that
(mnvs \oplus k1 \dot k2) \otimes ijq4
is better code than
frop (glort ( foo (mnvs, k1), k2), ijq4)
if only because it's easier for humans to parse, and with a restricted
set of operators, your're forced to chose something at least a little
better than "frop."
> [IMP72 let you stick BNF in your programs so you could add any
> syntax you wanted. The problem was that everyone did, so before you
> could read an IMP72 program you first had to figure out what
> language it was written in. Experience with C++ tells me that even
> operator overloading can easily lead to unmaintainable code if you
> can no longer tell at a glance what each operator does. -John]
--
Richard Rogers (rrogers@cs.washington.edu)
Computer Facilities Director -- Northwest Center for Environmental Education
http://www.cs.washington.edu/homes/rrogers/nceepg.html
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.