At 14:02 +0100 1999/07/28, D. Tweed wrote:
>> As for a math description of references, one could take the view that one
>> always constructs objects a, with references r. Then what is indicated in
>> the language is often the object pairs (a, r) modulo the equivalence
>> relation that the references differ.
>
>I'm not sure this is a useful view to take given Lennart & Fergus's
>responses to my previous post saying that the actual references
>corresponding to named values in a compiled program can fluctuate over the
>course of program evaluation for various reasons. (I must admit I was
>surprised that this happens but I guess that's because the FL
>implementations in textbooks aren't that close to Power-User Haskell
>Systems(TM) like ghc & hbc :-) )
If this is a problem, one should create a type of reference that is stable
during the processes. A "reference" need not be something specific, such as
a computer address, but could be viewed as method that can be used to
address the object.
So say object (v1, a1) is copied over to object (v2, a2), where v1 = v2 are
the values and a1, a2 are the addresses. In order to make a stable
reference, one needs to create an object r which first points at a1 and
then at a2. Thus (v1, r) is altered into (v2, r), which in reality will be
viewed as identical, having the same reference.
The requirement of such a structure will surely affect the implementation
of compilers.
> Now I know this I think just throwing
>the stuff into a monad of some sort to indicate the non-determinism
>is as good a solution as any.
So I just wanted to give a logical description resolving this referential
transparency paradox. How one then chooses to wrap it up in a language is
another matter; it should then just be something that is convenient to the
user.
Hans Aberg
* Email: Hans Aberg <mailto:[EMAIL PROTECTED]>
* Home Page: <http://www.matematik.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
