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

[piercarl@sabi.demon.co.uk (Piercarlo Grandi)]

>>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> 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
$<a|b>$, 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.