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
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.