Re: OO, C++, and something much better!

[bbadger@jade.ssd.hcsc.com (Bernard Badger)]

In article <330794C0.55E@concentric.net> Alan Lovejoy <alovejoy@concentric.net> writes:
   Piercarlo Grandi wrote:
   > >>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes:
[...skip to Piercarlo]
   > For example in ``C'' 'sizeof' indicates a unary operator, and in
   > ``Pascal'' 'div' indicates a binary operator, and so on. ``C'' even has
   > a _ternary_ operator ('?:'), whose invocation syntax is rather
   > distinguished from that of three-argument procedures.
   > 
   > You may be a bit misled by your familiarity with ``Smalltallk'', which
   > makes it possible to use ``operator'' syntax only with symbols composed
   > of ``special' characters. But even in ``Smalltalk'' what really
   > distinguishes operators is the type of syntax they are used in, not
   > quite their appearance (even if it is that which implies the use of
   > operator-like syntax).

   Well, as you know, the only difference in the "syntax" of Smalltalk
   binary
   message sends and keyword message sends involves the form of the
   selector
   (a binary message selector must be composed of characters from a special
   lexicon, it can have no more than two characters, and unlike a keyword
   selector, it does not terminate with the ":" character).

   If "div" qualifies as an operator in Pascal on syntactical grounds
   (because 
   it does not use the "()" to bracket an argument list), why would the
   Smalltalk 
   message selector "div:" not also qualify as an operator on the same
   basis 
   (since it also does not use "()" to bracket an argument list)?
You go a bit off-track here.  Since Smalltalk doesn't use the applicative
"f()" syntax, the points about operators and "()" weren't meant to apply
to Smalltalk.  They were about other common PLs like FORTRAN, C, Pascal, Ada.
_Those_ languages _tend_ to treat functions as non-operators.  Usually this
_is_ a syntactic distinction only, which is what you are arguing against.

   Many seem to feel that any function name whose syntax matches that of
   symbols such as "+" as used in mathematical expressions is an operator,
   and that anything else is not.  Excuse me, but the only difference
   between
   such syntax and that of message selectors such as "and:" or "div:" in
   Smalltalk is the final ":" character in the function names.   That seems
   rather an insubstantial basis on which to distinguish between
   "operators" 
   and "non-operators."   Would the "div" operator in Pascal cease to
   qualify
   as an operator if its name were changed to "div:"?
[As above].

[...]
   to some well-defined math or computer science property.  For example,
   according
   to Jon Anthony, an "operator" in math should be a function of the form
   "f: A^n -> A".  That is precisely the sort of thing I was reaching for;
   the
   references to associativity, transitivity and commutativity were merely
   illustrative. And I agree that using any of those three properties as
   the
   criterion for determining what is or is not an operator in a programming
   language would be ill-advised.
Has anyone mentioned APL (Ken Iverson's A Programming Language) in this 
thread?  If I recall, APL had "operators" which transformed data and
"functors" which modified the operators.  For example "/" was a functor
which accepted a left-hand-side binary function and applied it repeatedly
("over") the right-hand-side value.  (See:  "+/a" is the sum over all elements
of vector "a".)  

   > alovejoy> Is there a useful semantic distinction between "function" and
   > alovejoy> "operator" in math?  If so, what is it?
   > 
[...]
   I don't like the idea of using syntax to define what an operator is.  
   Especially since that is not the basis for the distinction in math,
   which
   apparently uses the semantics of the function to make the distinction, 
   as I have suggested should be the case in computer science (whether we
   should use the same definition as in math is another question, however).

   And how would you use syntax to tell what is or is not an operator in 
   a visual programming language that used only icons and no lexical names?
I can't see much hope of resolution.  You'll always have languages with
slightly different notions and terminology.  Presumably a visual language
may find _some_ notion of operator and function useful and will define them
_in its own terms_.  Of course, within a _system_ that embraces many 
programming languages, you would expect ^H^H^H^H^H^H^ hope to find some 
consistency :-/

--
Bernard A. Badger	bbadger@mail.ccur.com