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: 103376,b87849933931bc93 X-Google-Attributes: gid103376,public X-Google-Thread: 114809,b87849933931bc93 X-Google-Attributes: gid114809,public X-Google-Thread: 1108a1,b87849933931bc93 X-Google-Attributes: gid1108a1,public From: piercarl@sabi.demon.co.uk (Piercarlo Grandi) Subject: Re: OO, C++, and something much better! Date: 1997/02/17 Message-ID: X-Deja-AN: 219312330 X-NNTP-Posting-Host: sabi.demon.co.uk X-Disclaimer: Contents reflect my personal views only References: <5de62l$f13$1@goanna.cs.rmit.edu.au> <32FB8B51.1759@concentric.net> <3302DB3E.F70@concentric.net> <33054E63.C2A@concentric.net> <330794C0.55E@concentric.net> Content-Type: text/plain; charset=US-ASCII Organization: Home's where my rucksack's Mime-Version: 1.0 (generated by tm-edit 7.94) Newsgroups: comp.lang.c++,comp.lang.smalltalk,comp.lang.eiffel,comp.lang.ada,comp.object Date: 1997-02-17T00:00:00+00:00 List-Id: >>> "alovejoy" == Alan Lovejoy writes: piercarl> Ah, but I seem to remember that the original observation By piercarl> Richard O'Keefe was that whatever in most languages one calls piercarl> operators is things that are used with ``operator'' *syntax* piercarl> (binary or unary), rather than procedure call syntax, not that piercarl> operators are those things indicated by ``special'' piercarl> characters, that is some sort of ``operator'' *lexicon*. [ piercarl> ... examples that operators are distinguished by their piercarl> syntactic role, usually infix/binary, prefix/unary ... ] alovejoy> Well, as you know, the only difference in the "syntax" of alovejoy> Smalltalk binary message sends and keyword message sends alovejoy> involves the form of the selector (a binary message selector alovejoy> must be composed of characters from a special lexicon, it can alovejoy> have no more than two characters, and unlike a keyword alovejoy> selector, it does not terminate with the ":" character). alovejoy> If "div" qualifies as an operator in Pascal on syntactical alovejoy> grounds (because it does not use the "()" to bracket an alovejoy> argument list), Not quite: because it has a syntactic role different from that of procedure calls. In Pascal and most other languages procedure calls use parenthetical applicative form, but operators use infix notation. Let's start from this point: that *if* a programming language has both procedure calls and operator uses, then they must look different somehow to be distinguished. Now *looks* can be either syntax or lexicon. Now the syntax role of operators seems to be rather more strongly disciminating role in most languages, and in maths, than their lexicon, even if often the lexicon is characteristic too. alovejoy> why would the Smalltalk message selector "div:" not also alovejoy> qualify as an operator on the same basis (since it also does alovejoy> not use "()" to bracket an argument list)? Not, because that is not a distinguished infix syntax; that's the syntax use for normal procedure/method calls. For the latter ``Smalltalk'' uses affix syntax, using the method selector name as the ``brackets''/``commas'' around the argument list, instead of parenthesis. Consider: Pascal: i := j div k; i := divide(j,k); Smalltalk: i <- j // k. i <- j dividedBy: k. Now affix syntax of the keyword message like the 'o1 p: o2 q: o3' form is the way to apply ``normal'' procedures/methods in ``Smalltalk'', and is/would be equivalent to something like 'p:q:(o1,o2,o3)'. it is interesting to note that ``Smalltalk'' rules tend to be a bit oddball: for unary selectors, which must be normal symbols, look in fact like postfix unary operators, and something like 'i div: b' looks very much like an operator. alovejoy> Many seem to feel that any function name whose syntax matches alovejoy> that of symbols such as "+" as used in mathematical alovejoy> expressions is an operator, and that anything else is not. Lexicon, not syntax, is probably you meant here. But then both in maths and in programming languages there are many operators, or at least entities so called, which are drawn from the lexicon of normal identifiers. What distinguishes them is that they must be used in some distinguished, usually briefer than function application, syntactic role. In most languages that have prefix/parenthetical application for ``normal'' procedures, operators have prefix/infix non parenthetical syntax; the distinction may often be very small. Consider something like 'ABS x' vs. 'abs(x)' in ALGOL68, or for that matter 'sizeof a' vs. 'sqrt(a)' in ``C''. alovejoy> Excuse me, but the only difference between such syntax and alovejoy> that of message selectors such as "and:" or "div:" in alovejoy> Smalltalk is the final ":" character in the function names. alovejoy> That seems rather an insubstantial basis on which to alovejoy> distinguish between "operators" and "non-operators." Would alovejoy> the "div" operator in Pascal cease to qualify as an operator alovejoy> if its name were changed to "div:"? Not at all. My point is that it is *not* the lexicon that makes a symbol into an operator, but a distinguished syntactic role, usually ``briefer'' than that of a normal procedure. In the ``Smalltalk'' case binary selectors _do_ have a distinguished syntactic role, which is indeed usually briefer (to the point that a length limitation to 2 characters is part of the rules for binary selectors). Consider conversely ``Smalltalk'' vs. ``Pascal'' vs. maths: Smalltalk: a div: b a // b Pascal: Div(a,b) a div b maths: div(a,b) a / b To me the difference is that in all cases there is an ``ordinary'' syntax and a ``dinstiguished' syntax, and that _usually_ the distinguished syntax is briefer/neater (otherwise there would be no advantage to using a distinguished syntax), and often it is briefer because the lexicon of operators is distinguished too, but not necessarily in either programming languages or maths. alovejoy> Whether it's an operator or not should depend either on some alovejoy> mathematical property of its semantics (e.g., it is required alovejoy> to be associative, or transitive, or commutative, or some alovejoy> such). [ ... ] For example, according to Jon Anthony, an alovejoy> "operator" in math should be a function of the form "f: A^n -> alovejoy> A". That is precisely the sort of thing I was reaching for; [ alovejoy> ... ] Ahhh, but is the definition of "operator" as in ``operator theory''; as you write a *function* is called an "operator [function]" if it is of the given form. But operator functions and operators are quite different entities. The discussion was really about what looks like operators. Now there are a lot of things that look like operators in maths, which do not indicate an operator function. Given that maths notation and programming language notation are up to the each and every author/programming language designer, stating precisely what is an operator is not quite possible; but one show examples and draw general rules. In maths operators are symbols that essentially always have some distinguished syntatic role, and very often are drawn from some distinguished lexicon too. After all, as in ``Lisp'', one could simply use the same syntax and lexicon for any symbol whatsoever; one can write: (+ a b) (plus a b) (do-a-+-operation-on: a b) (*be/very/careful->here* a b) The one disadvantage to not having a distinguished operator syntax (and perhaps lexicon) is verbosity; but then ``Lisp'' to me at least is as readable as any other programming language. Mathematicians are fond of shorthands; just consider Dirac notation $$, which is quite neat indeed. They might be useful in maths, where notational simplicity may help quite a lot. I am not quite sure that syntactic/lexical shorthands actually help in programming, but most programming language designers, in the doubt, provide some sort of maths-like distinguished syntax for operators. Operator theory is entirely another matter; it is just a theory of a class of functions. Further material on this minuscule but amusing topic... There is a classification of mathematical subjects online at: http://www.ma.hw.ac.uk/~chris/MR/MR.html and it has a searchable index, which returns quite a number of diverse topics as to the various meanings that can be related to "operator" in maths.