tsaari@ohdake.uta.fi (Antero Taivalsaari) (03/05/91)
In article <PCG.91Mar2185335@odin.cs.aber.ac.uk> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
GRANDI>I would also like to offer some very unusual definitions:
GRANDI>
GRANDI><value> A number.
GRANDI>
GRANDI><object> Synonym for <value>.
SAKKINEN>What utter nonsense!
SAKKINEN> ...
SAKKINEN>See for instance "Values and objects in programming languages"
SAKKINEN>by B.J. MacLennan (SIGPLAN Notices, December 1982).
SAKKINEN>It has been reprinted in a recent IEEE tutorial collection on OOP.
Very unusual definitions indeed!
Below is a (slightly extended) summary of MacLennan's paper that I
made recently when I was preparing slides for a presentation.
For a more thorough discussion on values and objects, refer
to the original paper:
MacLennan,B.J.,
Values and objects in programming languages.
ACM SIGPLAN Notices vol 17, nr 12 (Dec) 1982, p.70-79
Reprinted in Peterson,G.E. (ed):
Tutorial: object-oriented computing, volume 1: concepts.
IEEE Computer Society Press, 1987, p.9-14
Note that this paper is pre-object-oriented; it does not really discuss
objects from the viewpoint that we currently regard as "object-orientation".
Still, it provides an interesting (rather philosophical) characterization
of the nature of values and objects in programming in general.
---------------------------------------------------------------------------
VALUES:
- values are applicative
* they cannot be copied
* they cannot be counted
* it is not meaningful to talk about sharing of values
- values are immutable (read-only)
* they preserve referential transparency
- values do not possess time characteristics
* they are atemporal (timeless)
* they cannot be created or destroyed
* they cannot be "invented" but they are "found"
- values do not possess space characteristics
* they do not have a location
* they do not have size or structure
- values do not have identities
* they can be identified only via their extensional
characteristics
- values are inherently extensional
* it is not really meaningful to distinguish between a
description of a value and the value itself
* values are one-of-a-kind (singular) abstractions
In brief: values are pure (mental) abstractions
Values can be used to represent mental (for example mathematical)
constructs.
Note that in a strict sense there are no values in computers!
=> computers use objects to represent values
---------------------------------------------------------------------------
OBJECTS:
- objects are non-applicative
* they can be instantiated
* they can be copied
* they can be shared
- objects have a mutable state
* they can be changed
* they do not inherently preserve referential transparency
- objects possess time characteristics
* they are temporal, i.e. have a life-time
* they can be created or destroyed
* they cannot simply be found but they must first be constructed
- objects possess space characteristics
* objects have a location
* objects have size and structure
- objects have identities
* they can be identified independently of their state
* two objects can have the same form, but different substance
- objects have intension and extension
* it is feasible to distinguish between the description of
an object and the object itself
* objects can have different kinds of implementations
In brief: objects are concrete (representational) abstractions
Objects can be used to represent real-world entities; they can also be
used to represent "objectified" values.
---------------------------------------------------------------------------
-- Antero Taivalsaari
Department of Computer Science
University of Jyvaskyla/
University of Tampere
Finland
tsaari@jyu.fi, tsaari@cs.uta.fipcg@cs.aber.ac.uk (Piercarlo Antonio Grandi) (03/07/91)
On 5 Mar 91 14:12:53 GMT, tsaari@ohdake.uta.fi (Antero Taivalsaari) said:
tsaari> Nntp-Posting-Host: cs.uta.fi
tsaari> In article <PCG.91Mar2185335@odin.cs.aber.ac.uk>
tsaari> pcg@cs.aber.ac.uk (Piercarlo Grandi) writes:
pcg> I would also like to offer some very unusual definitions:
pcg> <value> A number.
pcg> <object> Synonym for <value>.
sakkinen> What utter nonsense!
sakkinen> ...
sakkinen> See for instance "Values and objects in programming languages"
sakkinen> by B.J. MacLennan (SIGPLAN Notices, December 1982).
sakkinen> It has been reprinted in a recent IEEE tutorial collection on OOP.
tsaari> Very unusual definitions indeed!
tsaari>
tsaari> Below is a (slightly extended) summary of MacLennan's paper that I
tsaari> made recently when I was preparing slides for a presentation.
tsaari> For a more thorough discussion on values and objects, refer
tsaari> to the original paper:
tsaari> VALUES: [ ... ]
tsaari> OBJECTS: [ ... ]
tsaari> In brief: objects are concrete (representational) abstractions
tsaari> Objects can be used to represent real-world entities; they can also be
tsaari> used to represent "objectified" values.
It is fairly obvious that I think that the above distinction is entirely
meaningless and artificial. What the author misses is that objects are
numbers with special encoding rules, in particular they are numbers
where part of their digits are encoded in their address. That is a very
restrictive and limiting view of things. It is the problem that
generates the EQ/EQUAL difference and all sorts of evil.
I have already posted an article in which hopefully I make clear that
'objects' are nothing than specially and restrictively encoded numbers.
Another view may be to look at things relationally:
object(unique_id*,contents)
or even
object(id*,type*,contents)
where the domain of all fields is the naturals (fields with a star are
part of the key). Note for example that technically there are no
negative numbers in a computer; they are just an encoding on the
naturals (and there can be several: 1 or 2's complements, sign
magnitude, ...). Actually there are not even any 32 bit naturals in a
byte addressed architecture; they are an encoding on 8 bit naturals
(normally, four digits in base 256). This is clearly demonstrated by
the fact that you can choose different encodings (small [1234] or big
endian [4321] and the other unholy variations like the PDP-11 [3412]).
Of course all this simply means that part of the information carried by
an "object" is encoded in its address and/or type tag. While this may be
a legitimate technology, to claim it is fundamental is extremely
misguided, because it makes one miss the point that there are many
alternatives.
I will add one point that maybe was not obvious in my other posting on
this subject: I regard 'field access' "functions" like .re or .im merely
as decoders, that decode, for example a 64 bit natural into one or the
other 32 bit natural that encoded a float. Under this radical but
correct view a type is nothing but an equivaltn class defined by all the
functions (decoders/encoders included!) that can be meaningfully applied
to a number.
I regard Hoare's little remembered paper "Notes on data structuring" in
"Structured Programming" as one of the lost jewels (even if it has a
couple of mistakes); I am well read, but I *never* found any other
programming book/paper that has the all important concepts of
cardinality of a type, of type constructors, and of minimal or not
packing.
Fianlly, I had the SIGPLAN article about values/objects in mind when
introducing this discussion; it is indeed the one that many years ago
convinced me of exactly the opposite conclusions that the author
reaches.
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uktsaari@tukki.jyu.fi (Antero Taivalsaari) (03/08/91)
tsaari> Objects can be used to represent real-world entities; they can also be tsaari> used to represent "objectified" values. grandi>It is fairly obvious that I think that the above distinction is entirely grandi>meaningless and artificial. What the author misses is that objects are grandi>numbers with special encoding rules, in particular they are numbers grandi>where part of their digits are encoded in their address. That is a very grandi>restrictive and limiting view of things. It is the problem that grandi>generates the EQ/EQUAL difference and all sorts of evil. grandi>I have already posted an article in which hopefully I make clear that grandi>'objects' are nothing than specially and restrictively encoded numbers. grandi>Finally, I had the SIGPLAN article about values/objects in mind when grandi>introducing this discussion; it is indeed the one that many years ago grandi>convinced me of exactly the opposite conclusions that the author grandi>reaches. Actually, your conclusions above are exactly the same as MacLennan makes in his paper. Objects themselves are not values -- they are encoded representations of values. You cannot define number 2 or color red in a computer without first associating it with some particular representation. In that sense, objects are simply a means for implementing representations for values. However, I agree with you in that this discussion is pointless. There are lots of more important aspects in object-orientation to ponder. Saying that objects are numbers with special encoding rules just does not bring any insight into what is so special about object-oriented programming compared to for example machine languages. -- Antero Taivalsaari Department of Computer Science University of Jyvaskyla/ University of Tampere Finland tsaari@jyu.fi, tsaari@cs.uta.fi
kers@hplb.hpl.hp.com (Chris Dollin) (03/08/91)
Piercarlo Antonio Grandi writes:
[omitted]
The difference is pure syntactic sugar; this is clearly illustrated in
Pop-2 where any function application "f(x,y,z)" can be written
equivalently as" x.f(y,z)".
[omitted]
Are you sure? In Pop-2's descendant Pop-11, which allos the same kind of mixing
of styles, the second expression is interpreted as f(y,z)(x) - ie, compute an
apply-able object with f(y,z) and apply it to x, rather than apply f to x,y,z.
--
Regards, Kers. | "You're better off not dreaming of the things to come;
Caravan: | Dreams are always ending far too soon."pcg@test.aber.ac.uk (Piercarlo Antonio Grandi) (03/11/91)
On 8 Mar 91 09:25:41 GMT, kers@hplb.hpl.hp.com (Chris Dollin) said:
kers> Piercarlo Antonio Grandi writes:
pcg> The difference is pure syntactic sugar; this is clearly illustrated
pcg> in Pop-2 where any function application "f(x,y,z)" can be written
pcg> equivalently as" x.f(y,z)".
kers> Are you sure?
No :-). Actually the example above is wrong. Damn. Let's say it is right
under poetic license... :-)
kers> In Pop-2's descendant Pop-11, which allows the same kind of mixing
kers> of styles, the second expression is interpreted as f(y,z)(x) - ie,
kers> compute an apply-able object with f(y,z) and apply it to x, rather
kers> than apply f to x,y,z.
In my 1971 edition (one of my proudest possessions) of the Pop-2 book on
pages 10 and 11 it says that writing 'x .f' or 'f(x)' or 'x f()' is
equivalent; both result in x being pushed on the stack and f's value
being invoked as a function. So far so good.
This would mean that 'x y z .f' (Forth style) would be equivalent to
'f(x,y,z)' and to 'x y z f()'.
I am in mixed mind as to whether x.f(y,z) should be really be read as
'f(x)(y,z)' or as 'f(y,z)(x)', but I think the only test is trying it
out... I'd rather like 'f(x)(y,x)', as '.' and '()' are really the same
operator, only one is prefix and the other is postfix, and they should
be left associative.
However, whatever way this goes, I hope the point is made that the POP-2
equivalence between 'x.f' and 'f(x)' does give the impression that
'a.m(b,c)', '(m a b c)', '(a :m b c)', 'm(a,b,c)' and 'a m: b and: c'
are really just different syntaxes for the same thing, or should be.
Now a word from our sponsor, the League for Member Function Freedom, and
the Free Overloading Foundation:
Getting back to some posting of mine in comp.lang.c++, I think that the
following should be made equivalent:
[1] struct s { ... virtual void f(int); ... };
void s::f(int n) { ... };
...
s *s1; ... s1->f(2); ...
[2] struct s { ... };
void f(virtual s &it, int n) { ... };
...
s *s1; ... f(s1,2); ...
Where 'virtual' applied to a parameter implies dynamic overload
resolution. Naturally I would advocate making it possible to have more
than one 'virtual' parameter (The Mutant CLOS From Outer Space :->), as
it is already possible to have static overloading on a single parameter.
--
Piercarlo Grandi | ARPA: pcg%uk.ac.aber@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.ukpaul@acheron.Rational.COM (Paul Jasper) (03/16/91)
In article <PCG.91Mar11151801@aberdb.test.aber.ac.uk> pcg@test.aber.ac.uk (Piercarlo Antonio Grandi) writes: > ... > In my 1971 edition (one of my proudest possessions) of the Pop-2 book on > pages 10 and 11... Does anyone know where I can get hold of a copy of this book? I believe the full title and authors are "Programming in Pop2" by Burstall, Collins and Popplestone. I too have fond memories and sometime I'd like to try out some of the concepts (e.g. dynamic lists, frozen values for function arguments) in an OO language, such as C++. Also, it has a great 1970's space age cover like an aluminum foil space suit with the name indented into it (the world's first Motif widget?)