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.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public X-Google-Thread: 109fba,b87849933931bc93 X-Google-Attributes: gid109fba,public X-Google-Thread: fac41,b87849933931bc93 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: Alan Lovejoy Subject: Re: OO, C++, and something much better! Date: 1997/02/14 Message-ID: <33054E63.C2A@concentric.net>#1/1 X-Deja-AN: 218922308 References: <5de62l$f13$1@goanna.cs.rmit.edu.au> <32FB8B51.1759@concentric.net> <3302DB3E.F70@concentric.net> 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-14T00:00:00+00:00 List-Id: Piercarlo Grandi wrote: > > >>> "alovejoy" == Alan Lovejoy writes: > > alovejoy> The semantics are defined by the **language**, not the > alovejoy> "grammar." And the operator "+" **names** an operation, in > alovejoy> this case addition. > > alovejoy> The compiler resolves the "+" operator to a built-in function > alovejoy> (that is, a compiler-defined inlined function or macro) as is > alovejoy> appropriate for each usage (assuming the language is > alovejoy> statically typed, and that dynamic method dispatch is not > alovejoy> required). > > Even in dynamically typed languages, as long as type inference can > resolve to a single type... This, and the following, seem pedantic > observations, and I can well imagine that you have written as you have > written merely to verbosely list all possibilities, but they are > important. > > Also, it need not be a builtin function, as the languages mentioned in > this thread, both Adas, ``Smalltalk''s of various ilks, and ``C++'', all > permit using the "+" symbol to be bound to both builtin and user defined > implementations, and more than one actually. I am rather sure that you > know this, and it is probably important (for reasons I mention later) > not to give the impression that usually/generally names that look like > operators symbols can only be bound to builtins. Yes. That's not what I was thinking (that operator symbols could only be bound to builtins), but I can see that someone might well have taken it that way, now that you mention it. In the classic languages, it was typical for names not constructed using alphanumeric characters to be reserved (not useable for programmer-defined entities). This is important only for understanding the history of the terminology, and the justifications and motivations behind said terminology. > [snip] > > But the conclusion is really that the set of operator symbols that a > language uses and the (syntactical) rules with which some of them are > used are a rather independent matter from which implementation the > symbol denotes, how many, and what is their nature (builtin, user > defined, macro implemented as an extracode, or whatever). Yes, exactly. Any token can be given any meaning, since semantic mapping is arbitrary. There is nothing special about "+", "=" or "return". They are all just sequences of lexical symbols (which is true in any language). This is why I don't like the idea of calling "+" an operator merely because of the lexical symbol(s) with which it is composed. Whether it's an operator or not should depend either on some mathematical property of its semantics (e.g., it is required to be associative, or transitive, or commutative, or some such) Is there a useful semantic distinction between "function" and "operator" in math? If so, what is it? > In all three language families (ada, smalltalk, c++) mentioned the > ability to use more or less arbitrary symbols for more or less arbitrary > implementations is regarded as significant notational convenience; > whether this actually amounts to much is not easy to say, but a > qualitative argument can be made: that in an OO context it gives > user-defined classes/types and the associated operations/procedures > notational equivalence with the builtin ones, and thus enhances > orthogonality and _notational_ abstraction, which may well be of some > use. Yep. Using the same notation for the same conceptual function or operation, regardless of whether the implementation is programmer-defined or "built in," certainly appears to "be of some use," at least in my experience. -- Alan L. Lovejoy | Why Smalltalk? Smalltalk Consultant | Because I don't want to follow the crowd, alovejoy@concentric.net | but to lead it.