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

[jsa@alexandria (Jon S Anthony)]

In article <yf3afp4nepm.fsf@sabi.demon.co.uk> 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.


> 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.

That's only because you've become attached to this idea that operators
and operations are some how defined by their "looks".  Not so.  If
anything, it is the other way around.  The semantics come first and if
it is deemed "special enough" to call out in a certain context, a
particular distinctive symbol (and much more rarely, syntax) is
chosen.


> 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.

Sorry, this is just is not true.  The following are operators on the
set of Reals and none have any "distinguished syntax".

f(x) = x^2 + pi*x^(1/3)

g(y) = y^3 + 2y*e^y

The next two do have special symbols:

x^(1/2), Square root

Sin(x)


> 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.

They are not simply "shorthands".  Nor "squiggles" for squiggle's
sake.  The notations are used as a way to more easily see or (even
better) assist in seeing emergent patterns from very complex notions.
The successful ones help in this and the ones that get discarded, or
simply fade away, don't.

As you point out:

> 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.

it isn't obvious that this helps a lot in programming.


/Jon
-- 
Jon Anthony
Organon Motives, Inc.
Belmont, MA 02178
617.484.3383
jsa@organon.com