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

[Alan Lovejoy <alovejoy@concentric.net>]

Piercarlo Grandi wrote:
> 
> >>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes:
> 
> [ ... mostly agreement, BTW, ... ]
> 
> piercarl> But the conclusion is really that the set of operator symbols
> piercarl> that a language uses and the (syntactical) rules with which
> piercarl> some of them are used are a rather independent matter from
> piercarl> which implementation the symbol denotes, how many, and what is
> piercarl> their nature (builtin, user defined, macro implemented as an
> piercarl> extracode, or whatever).
> 
> alovejoy> Yes, exactly.  Any token can be given any meaning, since
> alovejoy> semantic mapping is arbitrary.  There is nothing special about
> alovejoy> "+", "=" or "return".  They are all just sequences of lexical
> alovejoy> symbols (which is true in any language).  This is why I don't
> alovejoy> like the idea of calling "+" an operator merely because of the
> alovejoy> lexical symbol(s) with which it is composed.
> 
> Ah, but I seem to remember that the original observation By Richard
> O'Keefe was that whatever in most languages one calls operators is
> things that are used with ``operator'' *syntax* (binary or unary),
> rather than procedure call syntax, not that operators are those things
> indicated by ``special'' characters, that is some sort of ``operator''
> *lexicon*.
> 
> 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)?

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:"?

> 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).
> 
> This a bit dangerous (for user-defined operators); besides what really
> distinguished operator from procedure invocations in most languages is
> the invocation syntax, not the semantics of the associated procedure, or
> the lexicon from which the symbol is drawn (which *may* be restricted in
> some language though).

I was not seriously proposing that an operator is some function that
conforms
to the associative property, but rather that it is some function that
conforms
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.

> alovejoy> Is there a useful semantic distinction between "function" and
> alovejoy> "operator" in math?  If so, what is it?
> 
> I would say it's still syntax: operators, however fancily named, tend to
> be used in binary/unary syntax forms, and functions in applicative (name
> plus parenthesized arg list) syntax. The two can get a bit confused,
> especially for unary operators, as in programming languages (for example
> many ``C'' programmers haven't realized that 'sizeof' is an operator and
> not a function an write 'int a; a = sizeof(a)', instead of the more
> appropriate 'sizeof a').
>
> But then mathematicians invent notation all the time; they even have
> suffix operator (e.g. "!" for factorial) or "around" operators (like
> "||" for absolute value) and many more types beside. The common thing is
> not quite that they use non-alphabetic symbols, but that they don't use
> applicative syntax like 'f(....,....)'; consider for examples of
> alphabetic operators commonly used in maths things like the 'lim' unary
> operator notation, or 'sup' as used in Knuth vol 1.

Smalltalk doesn't have "applicative" (name plus parenthesized arg list) 
syntax for message selectors.  Does that mean that all Smalltalk message
selectors are operators?  What about message selectors such as "print"
or
"size"?

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?

--
Alan L. Lovejoy		| Why Smalltalk?
Smalltalk Consultant    | Because I don't want to follow the crowd,
alovejoy@concentric.net	| but to lead it.