Re: Definable operators (was: Problems with Hardware, Languages, and Compilers)

rrogers@cs.washington.edu (Richard Rogers)
13 Mar 1997 23:45:16 -0500

          From comp.compilers

Related articles
Problems with Hardware, Languages, and Compilers hrubin@stat.purdue.edu (1997-03-07)
Definable operators (was: Problems with Hardware, Languages, and Compi rrogers@cs.washington.edu (1997-03-09)
Re: Definable operators (was: Problems with Hardware, Languages, and C sethml@ugcs.caltech.edu (1997-03-13)
Re: Definable operators (was: Problems with Hardware, Languages, and C rrogers@cs.washington.edu (1997-03-13)
Re: Definable operators (was: Problems with Hardware, Languages, and C creedy@mitretek.org (1997-03-14)
Re: Definable operators (was: Problems with Hardware, Languages, and C nmm1@cus.cam.ac.uk (1997-03-16)
Re: Definable operators (was: Problems with Hardware, Languages, and C andy@cs.Stanford.EDU (1997-03-16)
Re: Definable operators (was: Problems with Hardware, Languages, and C malcolm@sedi8.nag.co.uk (1997-03-16)
Re: Definable operators (was: Problems with Hardware, Languages, and C apardon@rc4.vub.ac.be (1997-03-18)
Re: Definable operators Dik.Winter@cwi.nl (1997-03-18)
[4 later articles]
| List of all articles for this month |

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


Post a followup to this message

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