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: 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: Alan Lovejoy Subject: Re: OO, C++, and something much better! Date: 1997/02/17 Message-ID: <330914F0.625A@concentric.net> X-Deja-AN: 219519374 References: <5de62l$f13$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-17T00:00:00+00:00 List-Id: Jon S Anthony wrote: > > In article piercarl@sabi.demon.co.uk (Piercarlo Grandi) writes: > > > 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. > > I think what you really want to say is simply that you don't think the > standard mathematical usage is appropriate in the context of PL > definitions. Alan, OTOH, seems to think that it is a good idea to > maintain some consistency with the mathematical usage. It's not > obvious to me which of these two views is "better". > > You seem to think that you can get useful milage out of this rather > vague and inconsistent sense used in PLs and programming. I'm not > sure why you think this is useful. Perhaps as a way of calling out > certain predefined restrictions and such in a PL definition. > > Alan seems to think that maintaining the mathematical sense at least > gives some solidity and clarity to the subject. True enough. But, > it's not clear to me that this sense would have any clear use in CS/PL > land. > > Also, "operator" and "operation" are used in various mathematical > settings in the way described, i.e., this usage is not restricted to a > particular branch or theory. It was useful to see Jon's interpretation of what I have said. Had I not seen this, I would not have realized that I need to make my position more clear :-) (I take full responsibility for not stating my case with sufficient clarity). I think one problem is caused by the distinction between a "descriptive" versus a "prescriptive" statement of the meaning and usage of the terms "operator" and "operation" in CS/PL. It is one thing to describe current practice ("descriptive"), and another to advocate a "proper" usage based on some idea of how things ought to be ("prescriptive"). None of us have always been completely clear with which attitude we were speaking. And as has been noted already, "current practice" varies among various languages. However, I am less interested in a description of current practice than I am in discussing how the terms should be used in language-independent CS discourse. In a previous post, I defined "operator" using syntactical distinctions (among other criteria). That definition was descriptive--of how the term is used in traditional, widely-used languages. But when I say that I think that the definition of "operator" should not be based on syntax, I am prescribing what I would prefer, not describing APL. I am definitely NOT advocating that the meaning of "operator" should be determined by its math meaning. I think that CS should fix the meaning of this term based on the needs and requirements of CS, not those of mathematics. Each culture and society develops its own lexicon, syntax, semantic system and taxonomy of the things important to life in that culture/society. Those who live near one of the poles may need many more words for snow than those who live on a tropical island near the equator. Those who implement procedures for machine execution of algorithms may need a different terminology than those who need to construct formal proofs in the domain of mathematics. What I like about the definition of "operator" in mathematics is that it is based on the semantics of the function, not its syntax. I think that a distinction based on function semantics is inherently more general, and much more likely to be useful in language-independent CS discourse, than one based on syntax. For example, I find the distinction between "built-in" versus "programmer-defined" procedure to be a more useful distinction than one between "standard" versus "special" function call syntax. There is no requirement for a language to even have a "special" function call syntax. Even if a language has more than one, it may not be possible to identify one as "standard" and the other(s) as "special." It is arguable, for example, whether or not the syntax of binary message sends in Smalltalk is "special." For that matter, one could also argue whether or not the syntax of unary message sends is "special." The case could be made that there are simply three different styles, all of which are "first class." The only differences are the number of arguments that are required/permitted, and the lexical symbols out of which the names of the functions can be constructed. Lacking any formal definition of "special syntax", the matter is purely one of opinion, not fact. So, Jon: Is that clearer? Are our positions closer than you had supposed? -- Alan L. Lovejoy | Why Smalltalk? Smalltalk Consultant | Because I don't want to follow the crowd, alovejoy@concentric.net | but to lead it.