IO monad and lazy evaluation

[Graham Klyne]

At 19:00 21/05/03 +0100, Glynn Clements wrote:
>More generally, the concept of "visible" semantics depends upon your
>(highly subjective) definition of "visible". I'm reminded of a recent
>BugTraq post regarding wiping sensitive information from memory; the
>code was basically:
>
>         char password[...];
>         read_password(password);
>         do_something(password);
>         memset(password, 0, sizeof(password));
>         return;
>
>The compiler inlined the memset(), then noted that the contents of the
>password array weren't used after the overwrite, so it optimised the
>overwrite away.

Security is always a tough case, since it has to be effective against 
activities that are outside the rules by which the legitimate players are 
operating.  (e.g. demonstrations of weaknesses in smart cards by subjecting 
them to physical environments in which they're never intended to function 
normally.)

So my definition of "visible", here, is restricted to what is visible 
through the language (as in my original example).

Your other point:
>Unfortunately, unless you also have a pure functional operating
>system, the ordering of I/O operations matters ;)

is well made, though I think there would be no problem in my case but for 
non-strict evaluation of the I/O result.  But, looking beyond I/O, I can't 
help wondering if these considerations extend to other situations in which 
one might use monads.  e.g. under what circumstances are monads safe to use 
in a multiprocessor environment?

#g


-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E