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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no 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: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public From: pcg@aber.ac.uk (Piercarlo Grandi) Subject: Re: OO, C++, and something much better! Date: 1997/02/12 Message-ID: #1/1 X-Deja-AN: 218347889 Sender: pcg@saturn.dcs.aber.ac.uk X-Disclaimer: Warning - Sender not verified References: <5de62l$f13$1@goanna.cs.rmit.edu.au> <32FB8B51.1759@concentric.net> Organization: Prifysgol Cymru, Aberystwyth Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object Date: 1997-02-12T00:00:00+00:00 List-Id: >>> "alovejoy" == Alan Lovejoy writes: alovejoy> Richard A. O'Keefe wrote: Richard> [ ... ] I think any fair person would agree that calling "+" an Richard> operator is not _wholly_ unreasonable, even in Smalltalk. The Richard> _application_ of "+" to arguments is a message send, but Richard> "message send" is no more and no less than "dispatched Richard> procedure call". Richard> Anyone saying that "+" is not an operator in Ada, for example, Richard> on the flimsy grounds that "+" is actually an overloaded Richard> function, would not be taken seriously. (Except in APL) Richard> "operator" is a syntactic property, not a semantic one. [ ... ] Quite so, but then: alovejoy> An "operator" is a "built in" function whose semantics is alovejoy> defined by the grammar of the language. The _semantics_ are defined by the grammar???? An operator like "+" is a _function_???? "+" is a symbol, a lexical entity; it will usually represent the plus operator, which is a syntactic entity, the name of an interface; such interface may well be that for one or more builtin procedures, which are the semantic entities. So we have that the representation of the plus operator is defined by the lexicon of the language, and is usually the "+" character; the plus operator has a usually definite role in syntax, and may or may not be, and usually is, the interface to several different _operations_ that have different semantics, which operations and their semantics are not defined by the grammar (unless one uses 2-level grammars as described by Uzgalis et al., but this is a really obscure if fascinating point that I guess was not meant by anybody in this thread). Some OO languages allow all three of affix, infix and prefix syntaxes for the plus operator, for example ``C++'', and affix syntax can only be used for ``member functions'', and infix only for non member (non builtin?) functions, as in: class Int { int i; public: Int operator +(Int,Int); .... }; int i(1); // In recent ``C++'' versions, BS has reintroduced the "thin // ice" ambiguity int j(2); // These are legal (void) i + i; // infix (void) j + j; // infix (void) j.operator +(j); // affix // These _ought_ to be legal, and some may well be in some version of // ``C++'' out there. (void) operator +(i,i); // prefix (void) i.operator+(i); // affix (void) operator+(j,j); // prefix In Smalltalk-80, unconventionally, there are no reserved operator symbols; but all symbols that are formed out of a certain set of special characters can/must be used in an affix role that _looks_ like (because of the absence of ':') infix notation, and might even be regarded as infix. What is builtin in Smalltalk-80 is not operator symbols (the ``message selector'') but the primitive bytecodes to which they resolve (the ``method''), which is an operation, not an operator. And so on...