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

[Alan Lovejoy <alovejoy@concentric.net>]

Richard A. O'Keefe wrote:
> 
> Alan Lovejoy <alovejoy@concentric.net> writes:
> >An "operator" is a "built in" function whose semantics is defined by the
> >grammar of the language.  The "name" of an operator is usually either
> >reserved, or else would not be a syntactically valid programmer-defined
> >function identifier.
> 
> 1.  "operator" is one of those words like "type".

Ok.  Given what you say below, I see what you mean.

> 2.  Grammars do not define the semantics.

Yes, sorry.  **Languages** specify a grammar and a mapping between
sentences 
and their meanings.

> 3.  Let's take "+" in Ada as an operator (because that's what the Ada
>     standard calls it).  It is not *A* built in function, it is several.
>     And it is not a _fixed_ set, but a set which can be expanded.

Yes, an operator (or more precisely, an operation) is not just one
function.  
Again, sorry for being imprecise.  What I should have said:

	An "operator" names a "built in" operation whose semantics are defined 
	by the programming language specification.  The code emitted by the
	compiler for an operation will either be a call to some built-in 
	(or perhaps user-defined) function, or will be generated inline as 
	specified by some macro function/template defined in the compiler. 
	The compiler may emit very different code for the "same" operation,
	depending on the context in which the operator was used (e.g., 
	integer addition versus complex number addition).

>     Guess what?  "+" in Smalltalk is exactly the same.  The language
>     provides some built-in readings for "+" to which you can add your own.

Note that I pointed out that "+" was one of a special set of message
selectors 
whose meaning was defined by the langauge.  The difference is that there
is nothing special about the syntax of "+" (that does not also apply to
any
other binary message selector).

> 4.  In Prolog, "operator" is a _syntactic_ property of symbols having
>     _no_ semantic consequences whatsoever.   When people talk about
>     "operator precedence languages", they are similarly referring to
>     purely syntactic properties.
>
> 5.  In Prolog and Pop, both of them languages where the programmer can
>     define new operators, the set of symbols usable as operators and the
>     set of symbols usable as `function' names are identical.  In APL,
>     user-defined functions _are_ niladic, monadic, or dyadic operators;
>     ALL of them.

So?  Terminology differs from language to language.  I was trying to
provide a definition that would be valid for most commonly-used
langauges
(which IMHO would not include Prolog, Pop or APL).  That my definition
does 
not jibe with the terminology of each and every language is neither
surprising
nor disturbing, IMHO.  I'm sorry if that doesn't fulfill the goals you'd
like
to set for the definition.  We each have our own agendas.

And if ALL functions are operators, then the distinction is meaningless:
the difference that makes no difference is not a real difference.

> >In languages that permit "operator overloading," there will be syntactic
> >(and usually semantic) constraints on the definition of an "operator"
> >that would not apply to other functions.  For example, the name of an
> >operator would have to be the same as one of the "built in" operators.
> 
> 6.  In Ada and C++, the only restriction on programmer overloading of
>     infix operators is that they take two arguments.

False:  I cannot name an operator whatever I choose.  I cannot invent
new
names, not even ones chosen from a set of legal characters.

>     But this is a fact about *those* languages, and *only* about those
>     languages.  It is not a fact about operators.  In Algol 68, from
>     which the designers of Ada and of C++ learned, programmers could
>     and did define any operators they wanted.  In Fortran 90, the third
>     "major" current language having operator overloading, there is an
>     infinite set of programmer-definable operators.  In S, there is an
>     infinite set of programmer-definable operators.
> 
> In short, you are confusing specific details that happen to apply to
> a _few_ languages with general properties of operators in general.

An alternative interpretation is that the term operator means different
things in different languages--a point you yourself have alluded to,
I believe.  As I said, I was trying to define "operator" so that it
would be consistent with the usage of the term in FORTRAN, COBOL, BASIC,
Pacal, C, C++ and other very commonly used languages.  I don't think
the term "operator" means the same thing in Pascal as it does in
Fortran-90
or in S, let alone APL or Pop.

> To return to the specific case in point, the form
> 
>         X + Y
> 
> in Smalltalk involves
>  - a symbol written infix between two expressions
>  - which is drawn from a small language-defined set of symbols which
>    can appear in that position
>  - for which the language partially defines the semantics
>  - to which the programmer can add additional semantics

Yes, and the expression

	X and: Y

in Smalltalk involves
   - a message selector written infix between two expressions (it's 
     certainly not "prefix" or "postfix" or "affix")
   - which is drawn from a small language-defined set of symbols which
     can appear in that position (the alphanumeric characters, which is 
     arguably a "small" set)
   - for which the language partially defines the semantics (in some
     implementations, #and: will be a "no lookup" message if the
     receiver is a Boolean)
   - to which the programmer can add additional semantics

So which one is an operator?  Neither?  Both?

> Is there any aspect of this, relevant to the question of "notations that
> help people avoid errors", which materially differs from the situation
> in Ada?  Is there any aspect of this which makes it unreasonable to
> call "+" in Smalltalk an (infix) operator?

I don't know.  I said in my post that "+" may be an operator, because
it may invoke a built-in operation.  It's just not an operator for any
syntactical reasons.  Without a definition of operator, how can this
be decided?  I provided a definition I like (after the ammendments I
offered due to your valid criticisms).  I have yet to see your
definition,
though.

> The one and only thing present in Ada and C++ which is lacking here is
> a notion of "precedence".  All "infix operators" in Smalltalk have the
> same precedence.  But APL is exactly the same:  there is no operator
> precedence in APL either, and no-one says the symbols are not operators!

No, all **binary selectors** have the same precedence.  A keyword
selector
with two arguments (one receiver and and one argument in ST jargon)
also has "infix" syntax--and all such also have the same precedence.

> >A programmer-defined operator named "=" would probably be constrained to
> >have a Boolean return type, and to have only two arguments.
> 
> You might actually take a look at C++ some time.  About having two
> arguments, you are right.  _Any_ infix operator has to have two
> arguments.  This is a fact about _syntax_.  But there is no such
> restriction on the result type.

Note I used "=" and not "==".  That was deliberate.  I was not thinking
of C++ per se.

And it is demonstrably false that an infix operator can only have two
arguments:  "x ? y : z" is an infix operator that takes three arguments.
Q.E.D.

> >The "+" operator would be constrained to have only two arguments,
> 
> The "+" thingy in Smalltalk gets two arguments as well.  How does that
> make it not an operator?

For the same reason that "on:" is not an operator?  All keyword
selectors
with only one ":" must also have exactly two "arguments" (or argument
and
receiver, in Smalltalk jargon).

But I was not arguing that "+" is not an operator in Smalltalk, but
rather
that if it is, it is not because of its syntax.

You can use syntactical distinctions to define what is and what is not
an operator if you choose.  But I don't see the utility of defining the
term that way.  Basing the distinction on a semantic difference of some
sort would seem to be more productive.  But to each his own.

> >and would have a predefined and unchangeable evaluation order precedence.
> 
> You are muddling up the syntactic notion of precedence with the
> semantic notion of evaluation order.  ...

Really? Would you care to be more specific on how my voluminous comments
on 
the nature and definition of "precedence" and "evaluation order" have
"muddled" 
the two?  Are you claiming there is no relation between them, and that
any
statement that implies such a relation improperly "muddles" them?

>.. The evaluation order of overloaded
> operators in Ada, C++, or Fortran is whatever you want it to be.

Well, when I learned C++ in the late eighties, the precedence of
operators 
was fixed, IIRC.  If the situation has changed since then (or my memory
is 
faulty), then I stand corrected.  However, if no one has yet written a
paper entitled, "Programmer-redefinable Operator Precedence Considered
Harmful," then I may have to do so.  It's bad enough to have to consult
a reference in order to determine what the precedence of an operator is.
To have the precedence be context-dependent based on the types of the
arguments... Shudder.

But this issue is not all that important to the definition of the term
"operator.".

>  And
> Smalltalk infix method calls *ALSO* have a predefined and unchangeable
> precedence.  It just happens that they all have the same precedence.  So?

So thay all have the same precedence, instead of having it determined on
a name by name (selector by selector, symbol by symbol) basis.  If I
define
a new method with the selector "@", its precedence is determined by the
fact that it is a binary selector, not by its specific name.

> >The reason that "+" would be considered an operator in languages that have
> >"operator overloading" is because the semantics of "+" is (partially)
> >defined by the syntax of the language.  One does not need to define the
> >meaning of "+" in Ada (as a function with source code) in order to use it
> >for integer addition.
> 
> This is again characteristically muddled.  The *syntax* of Ada has, and
> _can_ have, nothing to say about the *semantics* of the language.  ...

Yes. As I said above, I mispoke.  I should have said that "+" would be
considered an operator because its semantics is (partially) determined
by the language.

> ... The
> initial semantics of the "+" symbol in Ada are defined EXACTLY the same
> way that the initial semantics of the "+" symbol in Smalltalk are
> defined:  by definitions associated with particular types in the standard
> library.

As I said, "+" may in fact be an operator in Smalltalk, for just the
reasons
you give above.  I note that you are not arguing the case based on
syntax
here...

> I am very fond of Smalltalk.  You do it no service by pretending that
> there is a fundamental difference here, especially when you do not know
> Ada or C++ well.

I did not intend to imply that there is any fundamental difference, just
a syntactic one.  Why is that bad?  Or even inflammatory?

> True, you may be able to remove methods from "+" in Smalltalk, but that
> is not a special fact about "+" in Smalltalk or a special restriction of
> "+" in Ada.  You can't remove methods from _anything_ in Ada or C++.

I mentioned the possibility of removing "+" from the system in order to
show that the semantics of "+" is "built in" to most Smalltalk
implementations,
in support of the idea that "+" may in fact be an operator in
Smalltalk.  
I am sorry if anyone thought I was trying to say "see, Smalltalk is
different,
and more powerful and just all around better."  That was NOT the message
I was trying to convey, and I am mystified why anyone would have thought
so.

Was it, perhaps, due to my .sig?

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