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: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,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/18 Message-ID: <5eb4s4$jj5$1@goanna.cs.rmit.edu.au> X-Deja-AN: 219769765 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> 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-18T00:00:00+00:00 List-Id: Alan Lovejoy writes: > 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). I am left with absolutely no clue *whatsoever* about what you mean by "operator". When _I_ say "operator" (except in APL, which uses "operator" to mean something rather like "higher order function"), I refer to a syntactic property of a symbol. This interpretation is consistent with all of the current major languages, including Ada, BASIC, C, C++, COBOL, Fortran, Pascal, and even things like Matlab. Whether a particular symbol must be used as an operator, must be used as a `function' (the x $ y -vs- $(x, y) distinction) or may be used as either varies from symbol to symbol and language to language. However, in all of the languages I mentioned, there is ***NO SEMANTIC DIFFERENCE*** between symbols that may be used as operators and symbols that may not. In Ada, "abs X" involves the use of an operator. In Fortran, "ABS(X)" involves the use of a "function". But the range of *semantic* possibilities is *identical* for both languages. (For people who have not been keeping up, Fortran 90 has modules, user defined data types, and overloading.) There is a useful *syntactic* distinction between "normal functions" f(x), g(x, y) "operators" f x x g y "special syntax" <> x[y] but it is *only* a syntactic distinction. In all three cases, - the form names a built in operation - whose semantics are PARTIALLY defined by the language specification - the generated code may call a "normal function" - the generated code may be in-line - the "same" form may result in very different code depending on context. All of this applies to sqrt(x) and even a[i] just as much as to x+y. And all of this applies to Smalltalk just as much as for Ada. BY YOUR VERY OWN DEFINITION, "+" IS AN OPERATOR IN SMALLTALK. - "+" is built in. - its semantics is partially defined by the language. - the generated code may involve a normal method call - or it may involve in-line code (yes there are Smalltalks that do this) - the "same" form may result in very different code (again, there _are_ Smalltalks where one instance of "+" will result in certain in-line code, while another results in different in-line code). >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). So how on earth is this supposed to make it _not_ an operator? When you say there is nothing about "_" that does not also apply to any other binary message selector, you should also point out that the set of binary message selectors in Smalltalk is CLOSED. There is a small fixed set of binary message selesctors in Smalltalk and they are all written infix. By my criterion, they are all "operators". By your criterion, as shown at the beginning of this message, they are all "operators". In Algol 68, APL, Fortran 90, Prolog, and S, the set of operators is not closed. Programmers can and do give symbols of their own invention operator syntax. In Fortran, there is nothing about "+" that does not apply to a programmer-defined operator like '.PLUS.' except for - precedence - predefined partial semantics. In Smalltalk, the differences are _less_. >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). Well, it wouldn't include Smalltalk either, would it? The definition you finally DID provide *DOES* entail that "+" warrants the name "operator" in Smalltalk. (Your definition also entails that every procedure and function is an operator, but we'll ignore that.) >I'm sorry if that doesn't fulfill the goals you'd like >to set for the definition. We each have our own agendas. Yes, but YOUR agenda was supposed to be "show that + is not an operator in Smalltalk". You have in fact provided a definition under which EVERY method name is an operator! >And if ALL functions are operators, then the distinction is meaningless: >the difference that makes no difference is not a real difference. But "all functions are operators" is YOUR definition. Remember that MY definition is whether a symbol is an operator, and if so, of what kinds, is a purely syntactic property. A symbol is - a niladic operator if invocations are written "f" - a prefix monadic operator if invocations are written "f y" - a postfix monadic operator if invocations are written "x f" - an outfix monadic operator if invocations are written "f1 x f2" - an infix dyadic operator if invocations are written "x f y" >> >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. You didn't say "operator creation", you said "operator OVERLOADING". You can only overload something that already exists. Your specific restrictions were arity and result type. You were specifically WRONG about result type. Do you actually _know_ what the rules for operator naming are in - Algol 68? - Fortran 90? - S? - APL? If you have a method that wants two arguments (the receiver and one other), can you give it any name you want in Smalltalk and still write it infix? >> 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) [WRONG] > - 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? Clearly, both. Why do you have a problem with that? Note [WRONG] The method name "and:" is NOT drawn from the set of alphanumeric characters. It is drawn from the set of SEQUENCES beginning with a letter, etc etc etc and ending with a colon. That is in fact a very large set. So the set of infix operators in Smalltalk includes a large identifier-like set. Well, big deal. It's just the same in Fortran, except that a Fortran-90 extended operator name has to begin and end with a dot. >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. By your criterion, as copied at the beginning of this message, EVERYTHING (except perhaps, and only perhaps) literals, is an operator. At least my definition distinguishes some things that _are_ operators (for syntactic reasons; no other valid reasons exist) from a larger set of things that are _not_ operators. Your new definition here is that something is an operator if it may invoke a built-in operation, but then "sqrt(x)" in C involves an operator and "writeln('Foo!')' in Pascal involves an operator and we're left with no _distinction_ between things that are operators and things that are not. >> 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? See any good introductory flipping textbook. _Precedence_ is a purely syntactic notion having to do with the way forms are grouped in the absence of explicit bracketing. _Evaluation order_ is a purely semantic notion having to do with when things happen. The connection between them is extremely weak. For example, in S, x * y + z follows the normal _precedence_ order for infix operators. It has the same effect as (x * y) + z or even "+"("*"(x, y), z). However, it is a general property of S that the arguments of a function are evaluated _after_ the function has been entered. So in S, the evaluation order is 1a. evaluate "+" 1b. ENTER "+" 1c. depending on the implementation of +, either do 2, then do 3 or do 3, then do 2. 1d. depending on the types of the values of the arguments, do whatever kind of "addition" is required. 2a. evaluate "*" 2b. depending on the implementation of *, either evaluate x then evaluate y or evaluate y then evaluate x 2c. depending on the types of the values of x and y, do whatever kind of "multiplication" is required 2d. return the result. 3. evaluate z In fact, it is quite possible for "+" to evaluate z first, notice that it is NA (a special Not Available code) and immediately return NA without evaluating x*y at all. Again, consider C. x * y + z Precedence tells us that the grouping is (( x * y ) + z ). It also tells us that the execution of '*' will finish before the execution of '+'. But it tells us nothing about the evaluation order of x, y, and z. Their evaluation can be *arbitrarily* interleaved. Consider the example X * (Y + Z) in Fortran, which has perfectly ordinary operator precedence. The Fortran standards have for decades been crystal clear that "*" can notice that X is zero AND NOT EVALUATE Y+Z at all, even though on the "precedence is evaluation order" view the "+" "is evaluated" _before_ the "*". If "evaluation order" means anything at all, surely it has to mean "the order in which things are evaluated". And operator precedence constrains that order *VERY* weakly. In all seriousness, this is ELEMENTARY material. >>.. 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. The *PREDECENCE* is fixed. The *EVALUATION ORDER* most certainly, most deliberately, and most explicitly in the draft standard, is not. >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. This was a very odd thing, because your original claim was that "+" is NOT an operator in Smalltalk. Because I thought you were still arguing that "+" is NOT an operator in Smalltalk, I necessarily interpreted your statements about removing "+" as an argument FOR your position. Now you are saying that it was an argument AGAINST your position. Well, thanks. >I am sorry if anyone thought I was trying to say "see, Smalltalk is >different, But when you say that "+" is not an operator in Smalltalk, you ARE saying that 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? If you think anyone actually _read_ your .signature, you may be flattering yourself. I certainly didn't until now. I've deleted a large chunk of your message without replying to it in detail because I am finding this remarkably tedious. My conclusion: A. The distinction between operator precedence and evaluation order is a basic one that I would expect any CS graduate to have mastered. B. Whether something is an operator is a purely syntactic issue. C. In modern languages there is _NO_ semantic distinction between operators and other forms, although there may be a semantic distinction between language-defined forms and programmer-defined forms. D. I'm sick of this thread. -- 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.