Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!icdoc!qmw-cs!eliot
From: eliot@cs.qmw.ac.uk (Eliot Miranda)
Newsgroups: comp.object
Subject: Re: The Emperor Strikes Back
Message-ID: <3466@sequent.cs.qmw.ac.uk>
Date: 18 Mar 91 17:23:04 GMT
References: <PCG.91Mar10183850@aberdb.cs.aber.ac.uk> <1991Mar11.062302.18142@tukki.jyu.fi> <PCG.91Mar16143404@aberdb.test.aber.ac.uk>
Organization: Computer Science Dept, QMW, University of London, UK.
Lines: 86

Piercarlo Grandi writes:
>One of my problems is that at times I am too elliptic. I did not quite
>say that objects are *just* values. What I said that if you define
><type> as the set of all naturals to which a given group of function
>implementations is meaningfully appliable, then the notion of <object>
>becomes quite redundant, or else misleading.
>
So lets not. Lets define a type (in object oriented systems) as a
set of possible values (elements of the type)
and a set of possible operations where
	operations are performed upon instances of the values of the type
	operations are named
	operations return an instance of a type
	operations have a (possibly empty) tuple of argument types
which is a nicely recursive definition.
And if we're serious, types are themselves elements of some type.

>The reason, let's try to be clearer, is that what currently passes for
><object> as belonging to a <class> is really a particular, often
>Smalltalk-centric, implementation of <typing>. CLOS is the obvious (if
>incomplete) counterexample, even if one just uses its standard
>metaobject protocol.
Classes are ** implementations ** of types. In particular, classes may
be supersets of types (more operations, superfluous state (cacheing)).
And most importantly, there can be ** many possible ** implementations of
a type.
For often pressing pragmatic reasons this is a ** good ** thing. A programmer
can trade time and space by choosing apropriate implementations of types.
Ralph's Typed Smalltalk really depends on this distinction.

There is a real dilemma for the object-oriented software mix + matcher.
On the one hand that person wants to compose new types & manipulate elements of
these.  On the other hand that person wants performance (space & time) and
to achieve performance they require a more intimate connection between
code and state (need to know more about representations).
By making classes explicitly implementations and having a separate typing scheme
(name space, set of values) the programmer then gets the best of both worlds.
They specify their system in terms of types & tune their system in terms of
implementations of types (classes).

As I see it:
	ACTRA provides this my renaming types as classes & having a
	separate implementation hierarchy.

	Self addresses the problem by optimising the hell out of small, loosely
	coupled software modules by agressive inlining & speculative execution.

	Ralph's Typed Smalltalk provides this by adding types
	(albeit in a rather non-object way).

	<untyped> Smalltalk fudges the issue by horribly confusing types by
	classes.  isKindOf: is an ** abomination ** & I try never to use it.

Ralph, am I right to think that in your system types are simply denoted
rather than reified as objects? And if so are there reasons why this should
be so?

>
>I am a bit reluctant to continue a discussion on my idea of <type>
>because it is so unconventional and thus requires a lot of explanation,
>but I will try to mention some related work.
Piercarlo you are an inveterate TEASE!
Just work on your explanation. Yor idea of type is bound to be worth hearing
about (even if only to try & knock it down :-))

>I have recently noticed a definition of <type> that is in some way
>analogous, in the language Emerald. There a <type> is the set of all
>values to which a given set of functions *interfaces* is meaningfully
>appliable. I disagree about interfaces, because it is a purely syntactic
>requirement that creates what are IMNHO meaningless type equivalence
>classes; I prefer a semantics based partitioning. Yet the similarity is
>intriguing.
But in the functional world this is precicely what types are, they are
signatures of functions over values.  Which is what my definition above is.
In the object-oriented world we should (and do) define type as signatures of
functions over objects.  Of course you can reduce objects to values, by making
their identity part of their value tuple.  This may be a more useful way
of thinking about distributed object systems but for the moment I feel that
preserving an identity-value dichotomy is a useful & natural way of thinking.

-- 
Eliot Miranda			email:	eliot@cs.qmw.ac.uk
Dept of Computer Science	Tel:	071 975 5229 (+44 71 975 5229)
Queen Mary Westfield College	ARPA:	eliot%cs.qmw.ac.uk@nsf.ac.uk	
Mile End Road			UUCP:	eliot@qmw-cs.uucp
LONDON E1 4NS