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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public From: Alan Lovejoy Subject: Re: OO, C++, and something much better! Date: 1997/02/13 Message-ID: <3302F8B8.3F60@concentric.net> X-Deja-AN: 218489921 References: <5de62l$f13$1@goanna.cs.rmit.edu.au> <32FB8B51.1759@concentric.net> <5dua51$h41$1@goanna.cs.rmit.edu.au> Content-Type: text/plain; charset=us-ascii Organization: Modulation Mime-Version: 1.0 Reply-To: alovejoy@concentric.net Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object X-Mailer: Mozilla 3.01Gold (Win95; I) Date: 1997-02-13T00:00:00+00:00 List-Id: Richard A. O'Keefe wrote: > > 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". Ok. Given what you say below, I see what you mean. > 2. Grammars do not define the semantics. Yes, sorry. **Languages** specify a grammar and a mapping between sentences and their meanings. > 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. Yes, an operator (or more precisely, an operation) is not just one function. Again, sorry for being imprecise. What I should have said: An "operator" names a "built in" operation whose semantics are defined by the programming language specification. The code emitted by the compiler for an operation will either be a call to some built-in (or perhaps user-defined) function, or will be generated inline as specified by some macro function/template defined in the compiler. The compiler may emit very different code for the "same" operation, depending on the context in which the operator was used (e.g., integer addition versus complex number addition). > Guess what? "+" in Smalltalk is exactly the same. The language > provides some built-in readings for "+" to which you can add your own. Note that I pointed out that "+" was one of a special set of message selectors whose meaning was defined by the langauge. The difference is that there is nothing special about the syntax of "+" (that does not also apply to any other binary message selector). > 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. So? Terminology differs from language to language. I was trying to provide a definition that would be valid for most commonly-used langauges (which IMHO would not include Prolog, Pop or APL). That my definition does not jibe with the terminology of each and every language is neither surprising nor disturbing, IMHO. I'm sorry if that doesn't fulfill the goals you'd like to set for the definition. We each have our own agendas. And if ALL functions are operators, then the distinction is meaningless: the difference that makes no difference is not a real difference. > >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. False: I cannot name an operator whatever I choose. I cannot invent new names, not even ones chosen from a set of legal characters. > 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. An alternative interpretation is that the term operator means different things in different languages--a point you yourself have alluded to, I believe. As I said, I was trying to define "operator" so that it would be consistent with the usage of the term in FORTRAN, COBOL, BASIC, Pacal, C, C++ and other very commonly used languages. I don't think the term "operator" means the same thing in Pascal as it does in Fortran-90 or in S, let alone APL or Pop. > 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 Yes, and the expression X and: Y in Smalltalk involves - a message selector written infix between two expressions (it's certainly not "prefix" or "postfix" or "affix") - which is drawn from a small language-defined set of symbols which can appear in that position (the alphanumeric characters, which is arguably a "small" set) - for which the language partially defines the semantics (in some implementations, #and: will be a "no lookup" message if the receiver is a Boolean) - to which the programmer can add additional semantics So which one is an operator? Neither? Both? > 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? I don't know. I said in my post that "+" may be an operator, because it may invoke a built-in operation. It's just not an operator for any syntactical reasons. Without a definition of operator, how can this be decided? I provided a definition I like (after the ammendments I offered due to your valid criticisms). I have yet to see your definition, though. > 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! No, all **binary selectors** have the same precedence. A keyword selector with two arguments (one receiver and and one argument in ST jargon) also has "infix" syntax--and all such also have the same precedence. > >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. Note I used "=" and not "==". That was deliberate. I was not thinking of C++ per se. And it is demonstrably false that an infix operator can only have two arguments: "x ? y : z" is an infix operator that takes three arguments. Q.E.D. > >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? For the same reason that "on:" is not an operator? All keyword selectors with only one ":" must also have exactly two "arguments" (or argument and receiver, in Smalltalk jargon). But I was not arguing that "+" is not an operator in Smalltalk, but rather that if it is, it is not because of its syntax. You can use syntactical distinctions to define what is and what is not an operator if you choose. But I don't see the utility of defining the term that way. Basing the distinction on a semantic difference of some sort would seem to be more productive. But to each his own. > >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. ... Really? Would you care to be more specific on how my voluminous comments on the nature and definition of "precedence" and "evaluation order" have "muddled" the two? Are you claiming there is no relation between them, and that any statement that implies such a relation improperly "muddles" them? >.. The evaluation order of overloaded > operators in Ada, C++, or Fortran is whatever you want it to be. Well, when I learned C++ in the late eighties, the precedence of operators was fixed, IIRC. If the situation has changed since then (or my memory is faulty), then I stand corrected. However, if no one has yet written a paper entitled, "Programmer-redefinable Operator Precedence Considered Harmful," then I may have to do so. It's bad enough to have to consult a reference in order to determine what the precedence of an operator is. To have the precedence be context-dependent based on the types of the arguments... Shudder. But this issue is not all that important to the definition of the term "operator.". > And > Smalltalk infix method calls *ALSO* have a predefined and unchangeable > precedence. It just happens that they all have the same precedence. So? So thay all have the same precedence, instead of having it determined on a name by name (selector by selector, symbol by symbol) basis. If I define a new method with the selector "@", its precedence is determined by the fact that it is a binary selector, not by its specific name. > >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. ... Yes. As I said above, I mispoke. I should have said that "+" would be considered an operator because its semantics is (partially) determined by 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. As I said, "+" may in fact be an operator in Smalltalk, for just the reasons you give above. I note that you are not arguing the case based on syntax here... > 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. I did not intend to imply that there is any fundamental difference, just a syntactic one. Why is that bad? Or even inflammatory? > 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++. I mentioned the possibility of removing "+" from the system in order to show that the semantics of "+" is "built in" to most Smalltalk implementations, in support of the idea that "+" may in fact be an operator in Smalltalk. I am sorry if anyone thought I was trying to say "see, Smalltalk is different, and more powerful and just all around better." That was NOT the message I was trying to convey, and I am mystified why anyone would have thought so. Was it, perhaps, due to my .sig? -- Alan L. Lovejoy | Why Smalltalk? Smalltalk Consultant | Because I don't want to follow the crowd, alovejoy@concentric.net | but to lead it.