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: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) Subject: Re: OO, C++, and something much better! Date: 1997/02/13 Message-ID: <5dua51$h41$1@goanna.cs.rmit.edu.au> X-Deja-AN: 218454957 References: <5de62l$f13$1@goanna.cs.rmit.edu.au> <32FB8B51.1759@concentric.net> Organization: Comp Sci, RMIT, Melbourne, Australia Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object NNTP-Posting-User: ok Date: 1997-02-13T00:00:00+00:00 List-Id: Alan Lovejoy writes: >An "operator" is a "built in" function whose semantics is defined by the >grammar of the language. The "name" of an operator is usually either >reserved, or else would not be a syntactically valid programmer-defined >function identifier. 1. "operator" is one of those words like "type". 2. Grammars do not define the semantics. 3. Let's take "+" in Ada as an operator (because that's what the Ada standard calls it). It is not *A* built in function, it is several. And it is not a _fixed_ set, but a set which can be expanded. Guess what? "+" in Smalltalk is exactly the same. The language provides some built-in readings for "+" to which you can add your own. 4. In Prolog, "operator" is a _syntactic_ property of symbols having _no_ semantic consequences whatsoever. When people talk about "operator precedence languages", they are similarly referring to purely syntactic properties. 5. In Prolog and Pop, both of them languages where the programmer can define new operators, the set of symbols usable as operators and the set of symbols usable as `function' names are identical. In APL, user-defined functions _are_ niladic, monadic, or dyadic operators; ALL of them. >In languages that permit "operator overloading," there will be syntactic >(and usually semantic) constraints on the definition of an "operator" >that would not apply to other functions. For example, the name of an >operator would have to be the same as one of the "built in" operators. 6. In Ada and C++, the only restriction on programmer overloading of infix operators is that they take two arguments. But this is a fact about *those* languages, and *only* about those languages. It is not a fact about operators. In Algol 68, from which the designers of Ada and of C++ learned, programmers could and did define any operators they wanted. In Fortran 90, the third "major" current language having operator overloading, there is an infinite set of programmer-definable operators. In S, there is an infinite set of programmer-definable operators. In short, you are confusing specific details that happen to apply to a _few_ languages with general properties of operators in general. To return to the specific case in point, the form X + Y in Smalltalk involves - a symbol written infix between two expressions - which is drawn from a small language-defined set of symbols which can appear in that position - for which the language partially defines the semantics - to which the programmer can add additional semantics Is there any aspect of this, relevant to the question of "notations that help people avoid errors", which materially differs from the situation in Ada? Is there any aspect of this which makes it unreasonable to call "+" in Smalltalk an (infix) operator? The one and only thing present in Ada and C++ which is lacking here is a notion of "precedence". All "infix operators" in Smalltalk have the same precedence. But APL is exactly the same: there is no operator precedence in APL either, and no-one says the symbols are not operators! >A programmer-defined operator named "=" would probably be constrained to >have a Boolean return type, and to have only two arguments. You might actually take a look at C++ some time. About having two arguments, you are right. _Any_ infix operator has to have two arguments. This is a fact about _syntax_. But there is no such restriction on the result type. >The "+" operator would be constrained to have only two arguments, The "+" thingy in Smalltalk gets two arguments as well. How does that make it not an operator? >and would have a predefined and unchangeable evaluation order precedence. You are muddling up the syntactic notion of precedence with the semantic notion of evaluation order. The evaluation order of overloaded operators in Ada, C++, or Fortran is whatever you want it to be. And Smalltalk infix method calls *ALSO* have a predefined and unchangeable precedence. It just happens that they all have the same precedence. So? >The reason that "+" would be considered an operator in languages that have >"operator overloading" is because the semantics of "+" is (partially) >defined by the syntax of the language. One does not need to define the >meaning of "+" in Ada (as a function with source code) in order to use it >for integer addition. This is again characteristically muddled. The *syntax* of Ada has, and _can_ have, nothing to say about the *semantics* of the language. The initial semantics of the "+" symbol in Ada are defined EXACTLY the same way that the initial semantics of the "+" symbol in Smalltalk are defined: by definitions associated with particular types in the standard library. I am very fond of Smalltalk. You do it no service by pretending that there is a fundamental difference here, especially when you do not know Ada or C++ well. True, you may be able to remove methods from "+" in Smalltalk, but that is not a special fact about "+" in Smalltalk or a special restriction of "+" in Ada. You can't remove methods from _anything_ in Ada or C++. -- 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.