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

andy@cs.Stanford.EDU (Andy Freeman)
16 Mar 1997 23:29:35 -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)
Re: Definable operators (was: Problems with Hardware, Languages, and C jenglish@crl.com (1997-03-18)
Re: Definable operators fjh@murlibobo.cs.mu.OZ.AU (1997-03-18)
Re: Definable operators nmm1@cus.cam.ac.uk (1997-03-21)
[30 later articles]
| List of all articles for this month |

From: andy@cs.Stanford.EDU (Andy Freeman)
Newsgroups: comp.compilers,comp.lang.misc,comp.arch.arithmetic
Date: 16 Mar 1997 23:29:35 -0500
Organization: Computer Science Department, Stanford University.
References: 97-03-037 97-03-051
Keywords: design

Richard Rogers (rrogers@cs.washington.edu) wrote:
>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.


Yes, I think that definiable operators are worse than poorly chosen
value reference names. Definable operators share the "what is that?"
property of poorly chosen names, but they also have a "what is it
operating on?" problem.


Frankly, I see no "large" potential benefits. What I see is misguided
generalization from */+-.


Infix operators have two big problems. One is that infix
presumes/asserts two operands, which is often way too restrictive even
for the four basic aritmetic ops. The other is that infix requires
precedence rules, which no one agrees on.


Combine that with a bit of "definable operators can only use special
characters", and you get incomprehensible operator overloading. ("+"
is often a poorly chosen name, even if the language doesn't let you
choose a good one.)


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


Since different humans will parse the first different ways, the
asserted "ease" is getting in the way of communication.
(Interestingly enough, precedence advocates don't actually trust
prededence - as the above examples show.)


Since the operation in question really is best described as frop (if
it isn't, the example can be dismissed as a strawman), and has no
relationship to anything like "+", it's unclear why keeping me from
using frop and forcing me to use "+" is a good thing. The fact that
we have agreed on a set of glyphs for several common arithmetic
operations does not imply that those glyphs are good names for other
operations.


-andy
--


Post a followup to this message

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