On Wed, 28 Jul 1999, Hans Aberg wrote:
> At 17:15 +1000 1999/07/28, Fergus Henderson wrote:
> Actually, it is just an illusion that referential transparency is broken by
>
> > ref 27 <=> ref 27
> >
> >yields False.
>
> Because the semantic runtime meaning of this is that two different objects,
> a location holding information about "27", and the address (or reference)
> itself. The compiler, as a convenience to the user (called "abuse of
> language" by the Bourbaki team; see below), allows one to not indicate all
> information about "27" in the computer code itself.
>
> If we write out the full semantic information, then it would have looked as
> (27, ref1) <=> (27, ref2)
> and it is pretty clear that it would cause false as a result if ref1 is not
> equal to ref2.
[...]
> 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 :-) ) 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.
___cheers,_dave______________________________________________________
email: [EMAIL PROTECTED] "He'd stay up all night inventing an
www.cs.bris.ac.uk/~tweed/pi.htm alarm clock to ensure he woke early
work tel: (0117) 954-5253 the next morning"-- Terry Pratchett
