Matthias Blume wrote:
> In article <firstname.lastname@example.org> "Istvan.Simon"
> <email@example.com> writes:
> Even if two things LOOK the same then they are not the same. If they
> were the same you could never make a copy from anything. If this is
> true in reality then there is no reason to be untrue in programming
> Several misconceptions:
> - There are things in the "real" world that don't have an "identity".
> Numbers are one example, and we generally don't expect to be able
> to distinguish between _this_ 1 and _that_ 1. Another example is the
> electron (or other thingies that particle physicists might be interested
Nice analogy - especially as it can be used to prove that is *does* make
sense to obtain a pointer to an object:
While electrons are indistinguishable (and this is an important concept
quantum mechanics), it *does* make sense to speak of "the electron in
state" vs. "the electron in the 2p state", because there is the
Pauli principle, that no two electrons can be in the same state
this is true *only* for identical particles). In the same sense it makes
to speak of "the object at this place" and "the object at that place",
again no two objects can be at the same place. Of course, if you would
those identical objects in memory (without updating references to them),
would see no difference - just as you would see no difference if you
the two electrons above. It's the electrons "identified" by their state,
the objects "identified" by their address.
> - Things that _actually_ look the same in each and every
> respect_are_ the same. Things that we can distinguish between
> do _not_ look the same (by definition -- this is what we mean by
> being able to distinguish).
Even identical objects may be distinguished by their relationship to the
of the world. For example replace the two electrons of the example by
myons. Then it *would* make a difference, if the 1s myon or the 2p myon
decayed (although both are "identical"). In the same sense it makes a
f. ex. *which* of the identical subtrees you replace - you just get
trees by removing different subtrees, even if they are identical. Or,
take the following list: (1, 1, 2, 3). Now it *does* make a difference
replace the first 1 or the second 1 by 2. So we *can* distinguish
*this* 1 and *that* 1 (this 1 being the first in the list, that 1 being
> - Even if, for a moment, we assume that all "real world" things have an
> inherent identity (the electron is a nice counterexample), then
> it is _still_ a bad idea to extrapolate from this and make every
> value in a programming language the same. Abstract things (like
> numbers, functions, sets) do _not_ have an identity.
Such like the first 1 and the second 1 in the list above?
> - From a denotational point of view object identity doesn't matter
> for immutable things.
Ok, then I'll change the task: Create a new list with the first 1 or the
second 1 replaced by 2. Now, no difference?
> - Exactly _because_ there is no notion of identity, and because
> things that look the same _are_ the same, it is possible for the
> compiler to make copies of things (or represent them differently
> at different times during execution). This is of great value for
> optimizing compilers.
But *because* there is an identity, the compiler is not free to move
around without updating all references to them (else it could happen
composed objects *do* change by accident). And this in turn means that
objects from the program view are *not* moved around.
Or to say it a different way: A pointer is an object that *points* to
object. By doing this, it produces a *relationship* between itself and
object. And this relationship makes the object distuingishable from
"identical" objects. The fact that pointers are most easily are
physical memory address does nothing to the concept (in fact, the
in modern processors isn't really the address in memory - the object
even be swapped out of memory).
For this reason, a perfectly valid C++ implementation would be allowed
store f.ex. names in pointers, which then could be looked up in a hash
to find the object itself (does this sound somewhat familiar?). The
this is not done is that it would be much slower than the simple
to store just the address.
> You always have a memory address even you don't want to have one.
> This address will identify your object even if you don't want it.
> See, here is the mistake. If you don't have the concept of identity,
> then the compiler can choose to duplicate things when it needs to, it
> can keep things in registers instead of bundling them up and allocate
> them on the heap, it can use a hash-consing GC that identifies
> lookalikes the programmer didn't think of and represent them by the
> same "pointer" internally, and so on. Once you do any of this, you
> don't have _one_ pointer that identifies your value -- there might be
> two, or ten, or none at all.
But the compiler still has to keep track of which things belong to the
object - i.e. the object identity.
And C++ compilers also are allowed to optimize this way - storing values
registers is a common optimization technique in C++ compilers. And all
objects - including pointers - may be optimized away if the compiler
can prove that it doesn't need them to be there. And different variables
be stored in the same place under the as-if rule as well, if the
can proof that it won't change the program's behaviour. Under the as-if
pointers to different objects may even have the same physical value, if
compiler can proof that this won't change program behaviour.
I think the problem is just the (unfortunately very common)
that a pointer *is* a memory address - it's not more of a memory address
the letter 'A' is the number 65: it's how it is (usually) implemented.
A pointer is an abstraction, just as a letter or a number is an
A pointer is the abstraction of the concept "that one".