Re: "Object" types vs. "Value" types

[gauthier@unilim.fr (Michel Gauthier)]

In article <4jahd9$906@goanna.cs.rmit.EDU.AU>, ok@goanna.cs.rmit.EDU.AU
(Richard A. O'Keefe) wrote:

>>  gauthier@unilim.fr (Michel Gauthier) writes:
>>  >The initial publication about objects versus values is   [...]
>>  Surely the _initial_ publication of the idea goes back at least as far
>>  as Simula 67, which used ":=" for value assignment and ":-" for object
>>  reference assignment, precisely because they were understood as distinct.

Not quite that sure. You speak of a low-level language view, which cannot
imply anything at conceptual level view. MacLennan's paper is at this level.
Simula was a great pioneer language, which surely led to interesting concepts,
but most of them were discovered later. I leave to historians the work of
studying whether the object/value distinction was already in Simula, but
the example is too weak to conclude so.

>>  >  - lists organize objects only, and I am not sure that they are objects
>>  >     (they are not values)
>>  This is news to the functional programming community, who think that
>>  the sequence [1,2,3,4] is every bit as much a value as the sequence 1234.
>>  In functional languages, [1,2,3,4] = [1,2,3,4].

What happens if you try to insert something in this ? Either you have some
order property (which implies the location of your inserted item) or you must
indicate this location. These two behaviors should better correspond to 
different names (also see later). One is a value, the other is not.

As long as you cannot update things, _different_ things like cons(a,b) and
cons(a,b) are _non_distinguishable_. This is why pure functional languages
do not reach the problem.

I continue to assert that _non_distinguishability_ is essential if we want to
understand assignment.
 
>>  > - stacks and queues organize values only, and are objects
>>  (a) Why can't a stack or queue hold an object?  (Consider the case where
>>      this is the _only_ occurrence of the object.)

How can you define the relationship between the entered object, the kept object 
and the retrieved object ? How can you guarantee them to be the same ?

>>  (b) I have used stacks and queues in programming languages with no notion
>>      of assignment, no notion of object identity, and where two stacks
>>      holding the same sequence of values necessarily satisfied the
built in equality.

Yes, _built_in_ equality, but what is its meaning between objects ?
It can at most be the equality of their states, which are essentially values.
This leads us back to entered/kept/retrieved objectS.

>>     [...]
>>  We can all play definitional games if we want to.   [...]
>>  But this is to argue about *words* rather than *realities*.

Agreed with. I Apologize. There are some different kinds of lists :
 - sequences (most of public list packages)
 - structures built by a pointer head and a pointer record field
 - structures added to existing object classes such as to organize them
    as multiple easy_to_scan subsets
 - and probably others that I am not currently remembering
Use whatever name you wish, as soon as the different kinds are not confused.

Note that there can be 'value' sequences and objects to keep them (exactly 
like value arrays/records and object arrays/records).

>>  There is already a 'mutable'/'immutable' distinction around; how exactly
>>  does that relate to the 'object'/'value' distinction?

The 'mutable'/'immutable' distinction is part of the 'object'/'value'
distinction, but
there are many others.

----------          ----------          ----------          ---------- 
Michel Gauthier / Laboratoire d'informatique
123 avenue Albert Thomas / F-87060 Limoges
telephone +33 () 55457335 [or ~ 7232]
fax +33 ()  55457315  [or ~7201]
----------          ----------          ----------          ----------
La grande equation de la fin du siecle : windows-X = Mac-Y
The main end-of-century equation : windows-X = Mac-Y
----------          ----------          ----------          ----------
Si l'an 2000 est pour vous un mysticisme stupide, utilisez la base 9
If you feel year 2000 a stupid mystic craze, use numeration base 9
----------          ----------          ----------          ----------