Paul Wilson wrote:
> In article <izhggvrukk.fsf@mocha.CS.Princeton.EDU>,
> Matthias Blume <email@example.com> wrote:
> >In article <firstname.lastname@example.org> "Istvan.Simon"
> ><email@example.com> writes:
> > - 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.
My 5c worth: I suggest you are confusing an implicit idea of identity
for abstract objects (in a pure maths/logic sense) with the need to have
identity for pieces of information in a computational information
They are not the same problem.
In an information system, you potentially want to be able to
distinguish any object spatially (i.e. in the value-space) and
except those objects which are embedded unambiguously into a parent
This happens to include objects of "simple" types such as Integers
etc in many PLs, but if it didn't, you might want identification for
them as well, depending on the context of usage.
It is the context (i.e. what the information model and software is
which will determine the meaning of two objects conincidentally having
same value at some point in time: perhaps they are the same object -
if two objects representing the evaluation result of an equation in an
equation-solving system, it seems reasonable that they be treated as the
same object. But two string objects conincidentally having the same
such as "John Smith" is most likely to be .... coincidental.
- thomas beale