From: santas@inf.ethz.ch (Philip Santas)
Subject: Re: O.M() versus M(O) notation
Organization: Dept. Informatik, Swiss Federal Institute of Technology (ETH), Zurich, CH
Date: Mon, 17 Aug 1992 22:26:21 GMT


In article <PCG.92Aug16184526@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:
>
>johnson> Moreover, I don't think it is fair to complain that someone
>johnson> that uses several of these at once is being inconsistent, he is
>johnson> just blurring the distinction between something and its
>johnson> referent that people always do.
>
>And here we are at one of the crucial points of this discussion. The
>title of this thread is "O.M() versus M(O) notation", and my thesis has
>been that:
>  it makes a lot of difference which notation is used to describe
>  operations on a value
>because the notation strongly influences thought processes and actually
>constrains them (cfr. Dijkstra on BASIC), and that in particular the
>'O.M(...)' notation by making 'O' visually special suggests that
>overloading should happen only on the first argument, which is most
>probably a misleading impression, as overloading resolution ought to be
>symmetrical, which is the most "natural" thing.

Although I agree partly with this I have a major dissagreement:
you seem to argue that functions receive more than one arguments.
Well, all my functions receive one argument, and I think that most 
CS scientists and mathematicians agree with this.
 
Since I do not like the O.M(...) syntax and your functions with _many_ arguments, 
I propose you to consider (and comment) the following three cases:

 M (O,...)

where I have M receiving one argument consisting of an (...+1)-D tuple.

 (O,...) M 

where I have the tuple object receiving M

 O M (...)

Where O receives M as argument and
returns another function/object, which receives another argument etc.
The last two cases are much in accordance with OOPs message passing
concept, but are not more than normal functions.

>Given this thesis, fuzzy use of the word 'type' is quite a disaster.

You produced an artificial example, which, alas, expresses the opinion
of many (missinformed, as you said) programmers of what objects and messages 
are about.

>In the case of some languages, like Smalltalk, some of the subsetting
>must be manually implemented by the programmer, in fairly inappropriate
>ways.

Can you describe or outline a general purpose method for automatic subsetting?

>I am referring for example to deriving a stack class from a deque class;
>one needs to remove from the deque class the (unholy trinity)
>interface/implementation/specification of all the operations that
>operate at one of the two extremes of the deque, but Smalltalk, for
>example, does not allow this.
>
>Yes, one can *simulate* the removal of elements of an interface, for
>example, but this is achieved by redefining an implementation, which is
>quite inappropriate.

Concerning specification: I think that subclasses should inherit it as a whole,
otherwise there is no point for making a class subclass of another.
The problem with interface is that current OOPLs do not use functors
for classes, ie. functions which construct new classes out of older ones.
(here I use the term class as you use type. you may freely change the
notation)

Philip Santas

  "In an evolving universe those who stand still are really moving backwards"
--------------------------------------------------------------------------------
email: santas@inf.ethz.ch				 Philip Santas
Mail: Dept. Informatik				Department of Computer Science
      ETH-Zentrum			  Swiss Federal Institute of Technology
      CH-8092 Zurich				       Zurich, Switzerland
      Switzerland
Phone: +41-1-2547391