On 28-Apr-2000, Frank Atanassow <[EMAIL PROTECTED]> wrote:
> Jan Skibinski writes:
> > When can I safely cheat haskell compiler/interpreter
> > by pretending that I perform pure computations,
> > when in fact they are not? Here is a real example,
> > from my Md5Digest module which works fine in Hugs:
>
> I don't understand what is impure about the MD5 example, but the time example
> is clearly state-dependant. I think the bottom line is that unsafePerformIO
> has no semantics beside the fact that it _forgets_ the effectful semantics of
> the inner expression,
I think you should stop a bit earlier, and just say that the bottom line
is that unsafePerformIO has no semantics, period. It's certainly not
guaranteed that `unsafePerformIO' will "forget" the effects of the
inner expression. It might, of course, but then again it might not.
> and since we don't have an operational semantics for
> Haskell, you can in principle expect any "bad" use of unsafePerformIO to fail.
Yes, and you can in principle expect that any use of unsafePerformIO
might be "bad" for some future implementation.
> For example, even if you try to suspend the evaluation by guarding the
> expression with a (), as Nigel explained, a smart compiler could recognize
> that a function of type () -> a is denotationally equivalent to a constant
> of type a.
Actually that is not true in general, since the `()' type has two values,
namely `()' and bottom. But in specific circumstances a compiler could
perform optimizations like that.
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
