Thank you for the additional explanation, but it isn't clear that what
you have added is inconsistent with my explanation.
The point I was trying to make is that in an impure/imperative world,
you may assume that a function is called every time that you use it.
However, in a pure world the assumption is that a function called with
the same arguments will always return the same result (i.e.,
referential transparency) so that you only need to run it's code once
and then you can re-use that value henceforth.
In practice, of course, what happens under the hood (at least, with
GHC) is that "foo <- mkNext" constructs a thunk named "foo" which is
evaluated the at the first "print foo" and from then on the thunk is
in an evaluated state and so later references to it just use this
value rather than re-evaluating it. This is because, due to
referential transparency, it is equivalent to think of foo both as a
function whose value can be cached and as a constant value that we
just don't know yet.
The problem with the "foo" that was defined is that its code will
actually give you a different value each time that you run it,
violating the semantics of the language since all functions are
assumed to be pure. The problem with violating this semantic is that
the compiler uses it whenever it can to make things more efficient,
which in this case means treating foo as a value that only needs to be
evaluated once even though each time you run the code you actually get
a different result. Hence, the results are in a sense undefined since
the compiler is allowed to run foo as many times as it wants expecting
to get the same result each time; for example if two threads
evaluated foo at the same time then under pathological conditions the
first thread might see "1" and the second thread "2".
So the moral of this story --- and perhaps the point that you were
trying to make --- is that it is better to think of "foo" as a
constant value that you just don't know yet (until you evaluate) it
rather than as a function that you can call.
(Your nitpick that "next" would have been a better name than "foo" is
well taken, though.)
Cheers,
Greg
On Oct 22, 2009, at 12:48 AM, minh thu wrote:
2009/10/21 Gregory Crosswhite <gcr...@phys.washington.edu>:
And just because this has not been explicitly stated: it's not
just for
aesthetic reasons that you couldn't do this with a pure function, but
because it violates the semantics and gets you the wrong result.
So for
example, if you modified Tim's code to be
import Data.IORef
import System.IO.Unsafe
mkNext :: (Num a) => IO a
mkNext = do
ref <- newIORef 0
return . unsafePerformIO $
do
modifyIORef ref (+1)
readIORef ref
main :: IO ()
main = do
foo <- mkNext
print foo
print foo
print foo
Then the output that you will see (with GHC at least) is
1
1
1
because the compiler assumes that it only needs to evaluate foo
once, after
which it can cache the result due to assumed referential
transparency.
- Greg
This is indeed wrong, but not how you think it is.
The code you pass to unsafePerformIO has type Num a => IO a, so the
value passed to return has type Num a. So foo has type Num a too and
its value is 1.
Exactly like in
mkNext = do
ref <- newIORef 0
modifyIORef ref (+1)
readIORef ref
which is a complicated way to write
mkNext = return 1
Now, it's clear that foo has value 1 and printing it three times
should output three 1. The whole point of having mkNext return an
action (that should be called next, and not foo, as it is much
clearer) in previous code was too be able to execute it multiple times
and having it return a new value.
In general, expecting
print bar
print bar
print bar
outputing three different things is wrong, as bar should be pure. If
bar is not pure, then it should be
a <- bar
print a
b <- bar
print b
c <- bar
print c
Cheers,
Thu
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
