Paul Wilson wrote:
>
> In article <izhggvrukk.fsf@mocha.CS.Princeton.EDU>,
> Matthias Blume <blume@mocha.cs.princeton.edu> wrote:
> >In article <33607944.3852@ws6a17.gud.siemens.co.at> "Istvan.Simon"
> ><simo@ws6a17.gud.siemens.co.at> 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
system.
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
temporally,
except those objects which are embedded unambiguously into a parent
object.
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
about)
which will determine the meaning of two objects conincidentally having
the
same value at some point in time: perhaps they are the same object -
e.g.
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
value
such as "John Smith" is most likely to be .... coincidental.
- thomas beale
|