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

[Alan Lovejoy <alovejoy@concentric.net>]

Piercarlo Grandi wrote:
> 
> >>> "alovejoy" == Alan Lovejoy <alovejoy@concentric.net> writes:
> 
> alovejoy> The semantics are defined by the **language**, not the
> alovejoy> "grammar."  And the operator "+" **names** an operation, in
> alovejoy> this case addition.
> 
> alovejoy> The compiler resolves the "+" operator to a built-in function
> alovejoy> (that is, a compiler-defined inlined function or macro) as is
> alovejoy> appropriate for each usage (assuming the language is
> alovejoy> statically typed, and that dynamic method dispatch is not
> alovejoy> required).
> 
> Even in dynamically typed languages, as long as type inference can
> resolve to a single type... This, and the following, seem pedantic
> observations, and I can well imagine that you have written as you have
> written merely to verbosely list all possibilities, but they are
> important.
> 
> Also, it need not be a builtin function, as the languages mentioned in
> this thread, both Adas, ``Smalltalk''s of various ilks, and ``C++'', all
> permit using the "+" symbol to be bound to both builtin and user defined
> implementations, and more than one actually. I am rather sure that you
> know this, and it is probably important (for reasons I mention later)
> not to give the impression that usually/generally names that look like
> operators symbols can only be bound to builtins.

Yes. That's not what I was thinking (that operator symbols could only be
bound to builtins), but I can see that someone might well have taken it 
that way, now that you mention it.  In the classic languages, it was
typical for names not constructed using alphanumeric characters to be
reserved (not useable for programmer-defined entities).  This is
important
only for understanding the history of the terminology, and the
justifications
and motivations behind said terminology.

> [snip]
> 
> But the conclusion is really that the set of operator symbols that a
> language uses and the (syntactical) rules with which some of them are
> used are a rather independent matter from which implementation the
> symbol denotes, how many, and what is their nature (builtin, user
> defined, macro implemented as an extracode, or whatever).

Yes, exactly.  Any token can be given any meaning, since semantic
mapping
is arbitrary.  There is nothing special about "+", "=" or "return". 
They
are all just sequences of lexical symbols (which is true in any
language).  
This is why I don't like the idea of calling "+" an operator merely
because 
of the lexical symbol(s) with which it is composed.  Whether it's an
operator
or not should depend either on some mathematical property of its
semantics
(e.g., it is required to be associative, or transitive, or commutative,
or
some such)

Is there a useful semantic distinction between "function" and "operator" 
in math?  If so, what is it?

> In all three language families (ada, smalltalk, c++) mentioned the
> ability to use more or less arbitrary symbols for more or less arbitrary
> implementations is regarded as significant notational convenience;
> whether this actually amounts to much is not easy to say, but a
> qualitative argument can be made: that in an OO context it gives
> user-defined classes/types and the associated operations/procedures
> notational equivalence with the builtin ones, and thus enhances
> orthogonality and _notational_ abstraction, which may well be of some
> use.

Yep.  Using the same notation for the same conceptual function or
operation,
regardless of whether the implementation is programmer-defined or "built
in,"
certainly appears to "be of some use," at least in my experience.

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