From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public From: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) Subject: Re: OO, C++, and something much better! Date: 1997/02/25 Message-ID: <5etrns$sh3$1@goanna.cs.rmit.edu.au> X-Deja-AN: 221256240 References: <5de62l$f13$1@goanna.cs.rmit.edu.au> <32FB8B51.1759@concentric.net> <5dua51$h41$1@goanna.cs.rmit.edu.au> <3302F8B8.3F60@concentric.net> <5eb4s4$jj5$1@goanna.cs.rmit.edu.au> Organization: Comp Sci, RMIT University, Melbourne, Australia. Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object NNTP-Posting-User: ok Date: 1997-02-25T00:00:00+00:00 List-Id: jsa@alexandria (Jon S Anthony) writes: >In article <5eb4s4$jj5$1@goanna.cs.rmit.edu.au> ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) writes: >> There is a useful *syntactic* distinction between > ^^^^^^ >> "normal functions" f(x), g(x, y) >> "operators" f x x g y >> "special syntax" <> x[y] >I'm not convinced. Pleasant perhaps, but really useful? In what way? What I wrote was ambiguous. I did not mean that it was useful to _have_ the distinction. What I meant was that since the distinction has been imposed on us, it is useful to have a way of _talking_ about it. For example, if someone wants to know why the compiler doesn't like function +(Left, Right: Group_Element) return Group_Element is ... then it is handy to be able to say "+ is an operator, so you'll have to quote it". Any other word might have done just as well, but "operator" is the traditional word in programming. None of the well known programming languages even begins to come close to using "operator" in anything approximating a mathematical sense. >> So how on earth is this supposed to make it _not_ an operator? >Simple. For Alan the term "operator" should be distinguished by its >semantic. Yes, but he has completely failed to come up with a "semantic" that distinguishes "+" from anything else. The fundamental point here is that programming languages exist, and we need ways to talk about them clearly. It doesn't do anyone any good to go "whaa, *I* wanna call + a subroutine" or anything like that. It doesn't even do any good to say "whaa, _mathematicians_ say xyz", because (a) mathematical usage is by no means uniform, and (b) programming languages are a different domain of discourse, and the re-use of words in different domains is a standard feature of English. Let me cite Burris & Sankappanavar, "A Course in Universal Algebra". Ch II, Definition 1.1, p23. For $A$ a nonempty set and $n$ a nonnegative integer we define $A^0 = {\phi}$, and, for $n > 0$, $A^n$ is the set of $n$-tuples of elements from $A$. An $n$-{\it ary operation\/} (or {\it function\/) {\it on} $A$ is any function $f$ from $A^n$ to $A$; $n$ is the {\it arity} (or {\it rank\/}) of $f$. \dots An operation $f$ on $A$ is called a {\it nullary} operation \dots if its arity is zero. \dots An operation $f$ on $A$ is {\it unary}, {\it binary}, or {\it ternary} if its arity is 1, 2, or 3, respectively. Someone incorrectly claimed that the mathematical word for these things was "operator". It is in fact "operation". I think we can all agree that "+" is an _operation_ in any reasonable programming language (or an overloaded family of operations). I cannot find a definition of "operator" in that book, but on pp60ff it uses "operator" to refer to a mapping from classes of algebras to classes of algebras. Well, if we used _that_ notion of "operator" in programming languages, only the ML programmers would have anything to talk about. (And _they_ already call the things "functors".) Programming languages are a _different_ domain of discourse and we need a precise way of talking about them. The C standard defines "operator" (in section 6.1.5) to be the _syntactic_ notion "one of [ ] ( ) . -> ++ ... + ... ##". We may like or dislike this, but the fact remains that when talking about C, "operator" is a well-defined _syntactic_ notion. I'm reading this thread in comp.lang.ada. The Annotated Ada95 standard says, in section 4.5 (imagine ellipses almost everywhere): 1 The language defines the following six categories of operators... The corresponding operator symbols, and only those, can be used as designators in declarations of functions for user-defined operators. See 6.6, ``Overloading of Operators''. Syntax 2 logical operator 3 relational operator 4 binary adding operator 5 unary adding operator 6 multiplying operator 7 highest precedence operator One again, whether you like it or not, this _is_ the standard terminology for talking about Ada. The old ISO Pascal standard, 7185, defines four classes of "operators" in section 6.7.2: relational-operator adding-operator multiplying-operator not The current Pascal standard, 10206, defines five classes of "operators" in section 6.8.1. In addition, it distinguishes the comparison _function_ LT (and its relatives) from the relational _operator_ < (and its relatives). Again, like it or not, if you want to talk precisely about Pascal, you use the terminology in ISO 10206. The point that I am making is simply that there is an established word "operator" used consistently in the standards for many current programming languages to refer to a small set of built in operatIONS with special syntax. This isn't _intended_ to conform to any advanced mathematical usage. You may _regret_ the use of the word "operator" for a *syntactic* category in programming language standards, but it is humptydumptyism to try to pretend that it isn't so. -- limits on the scope of cooperation are often due to the inability to recognise the identity or the acts of the other playes. --R.Axelrod Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.