From: pcg@aber.ac.uk (Piercarlo Grandi)
Newsgroups: comp.object
Subject: Re: O.M() versus M(O) notation
Date: 16 Aug 92 18:45:26 GMT
	<__5mtrq.objsys@netcom.com> <PCG.92Aug14170701@aberdb.aber.ac.uk>
	<1992Aug15.124149.28538@m.cs.uiuc.edu>
Reply-To: pcg@aber.ac.uk (Piercarlo Grandi)
Organization: Prifysgol Cymru, Aberystwyth


On 15 Aug 92 12:41:49 GMT, johnson@m.cs.uiuc.edu (Ralph Johnson) wrote
things on which we are mostly in agreement (I am still pondering an
earlier article of his). I will pick some nits and emphasize some
differences in style here.

johnson> [ ... ] there are many different definitions of the word
johnson> 'type', and that sometimes the same person will use several of
johnson> the definitions at once.  He also does a good job of
johnson> enumerating the different kinds of definitions.  I'd like to
johnson> focus on one particular distinction, between a mathematical
johnson> object and a description of a mathematical object.

johnson> (Piercarlo Grandi) writes:

pcg> * why have 'type' have as referent the formal specification of a
pcg>   mathematical entity and not the mathematical entity itself?

johnson> Because all that we or our programs can manipulate is the
johnson> formal specification of a mathematical entity, and not the
johnson> mathematical entity itself.  [ ... ] The only way we can talk
johnson> about Integer is by giving a formal specification of it.  Thus,
johnson> we tend to call the formal specification 'Integer', too.
johnson> Although this might be a mistake from a philosophic point of
johnson> view, it seems to be a very common one, and one that nearly all
johnson> mathematicians make.

But professional mathematicians *know* that algebraic structures are not
quite the same thing as their descriptions, and they can also *rely* on
other mathematicians to know that as well.

johnson> For example, the lambda calculus crowd says that a type is a
johnson> set of values (a mathematical entity) and then they give a
johnson> syntax for specifying types and call such an expression a type!

Sloppy wording... It becomes dangerous when it begets sloppy thinking,
which happens by default unless there is a *strong* cultural tradition
that disambiguates the sloppy wording. Unfortunately this is not the case
with most computer science, computer scientists, and in particular
within OO programming.

pcg> (Bob Hathaway) said:

objsys> No, type and type systems are independent of implementation.  I
objsys> think this distinction is very important from both a compiler
objsys> and applications point of view.

pcg> But the compiler never sees any of 'type' and 'type system'! The
pcg> compiler only sees interfaces and implementations! Or, at best,
pcg> assertions that decorate them and are derived from specifications.

johnson> Bob is using 'type' as 'interface specification'.  I think he
johnson> is fairly consistent with this use,

Actually I have counted that he uses most often 'type' as 'abstract
specification', not as 'description of a protocol'.

johnson> though he also uses it to refer to the set of objects that meet
johnson> the interface.

And he also uses the same word for the specification of the semantics of
those objects. To me, it is quite hard to follow. I really cannot
imagine why it is so difficult to qualify 'type' with the proper
adjective at least every now and then, for example:

type denotation:	the algebraic structure;

type specification:	a description of the 'type denotation' using
			some suitable formal notation;

type implementation:	an intension of the functions in a 'type
			denotation' expressed in some particular
			notation.

type interface:		a way used to define/invoke the elements of the
			'type implementation' in some particular
			notation.

I would personally use 'type' alone for the 'type denotation', and use
'specification', 'interface' and 'implementation' on their own with the
obvious sense.

Let me now give some contrived example:

type:
	``fixed size deques'' (cannot do much better than this :->)

specification:
	... contents:: fsequence where capacity = limit ...
	... push x :: card contents < limit -> x ++ contents ...
	... append x :: card contents < limit -> contents ++ x ...

implementation:
	...
	push(self,item)
	{
	... if (diff_ring(self->top,self->bottom,self->slots) > 0)
	  self->ring[anticlockwise(&self->bottom,self->slots)] = item; ...
	}
	append(self,item)
	{
	... if (diff_ring(self->top,self->bottom,self->slots) > 0)
	  self->ring[clockwise(&self->top,self->slots)] = item; ...
	}
	...

interface:
	... template<T> void push(deque<T> &,const T); ...
	... template<T> void append(deque<T> &,const T); ... 

(please forgive mistakes and imprecisions :->).

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.

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

johnson> An abstract class is much more than just an interface
johnson> specification.  It also includes part of the implementation of
johnson> the class, but it has some 'holes' in it that subclasses must
johnson> fill in.  It is really a reusable design for subclasses, not an
johnson> interface specification.  Of course, in languages without
johnson> seperate interface specifications, people use abstract classes
johnson> to make a seperate entity in their program that is just
johnson> interface.

Then, wouldn't it be better to adopt a 'reusable, orthogonal' components
for building a class rather than leaving bits of a monolithic definition
missing?

I tend to think the former results in cleaner, less misleading notation,
and greater generality. As a rule, those notations in which the
primitive construct is a monolithic interface/implementation/specification
definition idiom tend to have bizarre rules and restrictions on how the
idiom can be subsetted and how subset definitions can be merged.

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

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.
--
Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
Dept of CS, University of Wales    | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk