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

[Alan Lovejoy <alovejoy@concentric.net>]

Jon S Anthony wrote:
> 
> 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.

It was useful to see Jon's interpretation of what I have said.  Had I
not
seen this, I would not have realized that I need to make my position
more
clear :-) (I take full responsibility for not stating my case with
sufficient
clarity).

I think one problem is caused by the distinction between a "descriptive"
versus a "prescriptive" statement of the meaning and usage of the terms
"operator" and "operation" in CS/PL.  It is one thing to describe
current
practice ("descriptive"), and another to advocate a "proper" usage based
on some idea of how things ought to be ("prescriptive").  None of us
have
always been completely clear with which attitude we were speaking.

And as has been noted already, "current practice" varies among various
languages.  However, I am less interested in a description of current
practice than I am in discussing how the terms should be used in 
language-independent CS discourse.  In a previous post, I defined
"operator" using syntactical distinctions (among other criteria).  That
definition was descriptive--of how the term is used in traditional,
widely-used languages.  But when I say that I think that the definition
of "operator" should not be based on syntax, I am prescribing what
I would prefer, not describing APL.

I am definitely NOT advocating that the meaning of "operator" should be
determined by its math meaning.  I think that CS should fix the meaning
of this term based on the needs and requirements of CS, not those of 
mathematics.  Each culture and society develops its own lexicon, syntax,
semantic system and taxonomy of the things important to life in that
culture/society.  Those who live near one of the poles may need many
more words for snow than those who live on a tropical island near the
equator.  Those who implement procedures for machine execution of
algorithms may need a different terminology than those who need to
construct formal proofs in the domain of mathematics.

What I like about the definition of "operator" in mathematics is that it 
is based on the semantics of the function, not its syntax.  I think that 
a distinction based on function semantics is inherently more general,
and 
much more likely to be useful in language-independent CS discourse, than 
one based on syntax.  For example, I find the distinction between
"built-in" 
versus "programmer-defined" procedure to be a more useful distinction
than 
one between "standard" versus "special" function call syntax.  There is
no requirement for a language to even have a "special" function call 
syntax. Even if a language has more than one, it may not be possible to 
identify one as "standard" and the other(s) as "special."

It is arguable, for example, whether or not the syntax of binary message
sends in Smalltalk is "special."  For that matter, one could also argue
whether or not the syntax of unary message sends is "special." The case 
could be made that there are simply three different styles, all of which 
are "first class." The only differences are the number of arguments that
are required/permitted, and the lexical symbols out of which the names
of the functions can be constructed. Lacking any formal definition of 
"special syntax", the matter is purely one of opinion, not fact.

So, Jon: Is that clearer?  Are our positions closer than you had
supposed?

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