RE: more unsafePerformIO questions (is it safe to use with ReadMode Handles)?
If the databases *do* change over time, then there are two possibilities:
1. the contents change due to external factors only 2. the contents change because this program doing the writing
in (1), you can still pretend the interface is pure, by imagining that all the changes happened earlier. This works as long as you only read the external data once.
Isn't there the possibility of inlining causing a read to happen twice even if it only appears to happen once?
In theory that would be a valid transformation, but in practice no compiler would duplicate arbitrary computations. GHC certainly doesn't. Cheers, Simon
On Tue, 19 Aug 2003 10:52:57 +0100, "Simon Marlow" <simonmar@microsoft.com> wrote:
Isn't there the possibility of inlining causing a read to happen twice even if it only appears to happen once?
In theory that would be a valid transformation, but in practice no compiler would duplicate arbitrary computations. GHC certainly doesn't.
I was thinking of a situation like let x = unsafePerformIO readFooFromDB in x+x I see from your "Secrets of the GHC inliner" paper that x wouldn't be inlined by GHC, but it seems to me like a serious abuse of the principle of referential transparency to write programs that _assume_ that. Cheers, Ganesh
G'day all. On Tue, Aug 19, 2003 at 11:11:23AM +0100, Ganesh Sittampalam wrote:
I was thinking of a situation like
let x = unsafePerformIO readFooFromDB in x+x
I see from your "Secrets of the GHC inliner" paper that x wouldn't be inlined by GHC, but it seems to me like a serious abuse of the principle of referential transparency to write programs that _assume_ that.
I would have thought that this was the principle of full laziness (which Haskell doesn't guarantee, but all compilers in practice support) was more important here. If the code instead was this: let x = expensiveComputation foo in x + x I would certainly hope that expensiveComputation wasn't called twice, and even though the language doesn't guarantee it, I have already written code that assumed it. Cheers, Andrew Bromage
Hi Andrew,
let x = expensiveComputation foo in x + x
I would certainly hope that expensiveComputation wasn't called twice, and even though the language doesn't guarantee it, I have already written code that assumed it.
I always thought that there is a tiny difference between "let" and "where": Using "let" "expensiveComputation foo" might be computed twice (depending on the compiler?). But using: x + x where x = expensiveComputation foo should compute the value for x only once. Therefore, I always try to use "where" for common subexpressions. Please correct me if I'm wrong here. Cheers, Jan
G'day all. On Wed, Aug 20, 2003 at 07:42:59AM +0200, Jan Scheffczyk wrote:
I always thought that there is a tiny difference between "let" and "where":
They're semantically equivalent. See, for example: http://haskell.org/onlinereport/decls.html#sect4.4.3.2 Cheers, Andrew Bromage
At 7:42 AM +0200 8/20/03, Jan Scheffczyk wrote:
Hi Andrew,
let x = expensiveComputation foo in x + x
I would certainly hope that expensiveComputation wasn't called twice, and even though the language doesn't guarantee it, I have already written code that assumed it.
I always thought that there is a tiny difference between "let" and "where": Using "let" "expensiveComputation foo" might be computed twice (depending on the compiler?). But using:
x + x where x = expensiveComputation foo
should compute the value for x only once. Therefore, I always try to use "where" for common subexpressions.
Please correct me if I'm wrong here.
The reserved word "let" introduces an expression (a "let-expression"), but there's no such thing as a "where-expression". The reserved word "where" can be used only in definitions. For example, 3 + ((x + x) where x = expensiveComputation foo) is invalid syntax, whereas 3 + let x = expensiveComputation foo in x + x is OK. And here's a use of "where" in a definition: let z = x + x where x = 2 in z*5 That could have been written using only "let": let z = let x = 2 in x + x where x = 2 in z*5 Watch out for the Hugs 98 command line-- it allows z*5 where z = x + x where x = 2 but that's not a truly valid expression, because you can't embed it in a larger expression: 2 + (z*5 where z = x + x where x = 2) is properly identified as a syntax error. Regards, --Ham -- ------------------------------------------------------------------ Hamilton Richards, PhD Department of Computer Sciences Senior Lecturer The University of Texas at Austin 512-471-9525 1 University Station C0500 Taylor Hall 5.138 Austin, Texas 78712-1188 ham@cs.utexas.edu hrichrds@swbell.net ------------------------------------------------------------------
participants (5)
-
Andrew J Bromage -
Ganesh Sittampalam -
Hamilton Richards -
Jan Scheffczyk -
Simon Marlow