In article <email@example.com> "Istvan.Simon"
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
- 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
- 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 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.
- From a denotational point of view object identity doesn't matter
for immutable things.
- 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
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.