On Tue, 27 Jul 1999, Simon Marlow wrote:
> > req a b = unsafePerformIO $ do
> > a' <- makeStableName a
> > b' <- makeStableName b
> > return (a' == b')
>
> That's exactly what to use in a situation like this. Pointer equality loses
> referential transparency in general (as Simon P.J. pointed out), hence the
> use of the I/O monad in our Stable Name API.
>
> Furthermore, if you intend to encapsulate your use of pointer equality in a
> "safe" abstraction, say a memo table, then use of unsafePerformIO is
> entirely justified. The req function above is of course an "unsafe"
> abstraction, because it exposes the representation of a and b.
Just an idle curiousity question: when you say it loses referential
transparency am I right in saying it this is only with respect to compile
time transformations (& program proofs,etc) but that there's no problem
_for a given compiled program_ about req a b changing it's value depending
upon the way demand drives the lazy evaluation reduction strategy, or is
there a subtlety there?
(I'm just curious about the use of the IO monad, which regulates
things which depend on the an underlying state which may change with time
in a difficult to predict way depending on the precise pattern of
reduction, rather than say a `compile time monad'.)
___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
