Sun, 02 Feb 2003 20:58:00 -0600
Patrik Jansson <email@example.com> wrote:
> On Fri, 31 Jan 2003, Jon Cast wrote:
> > Otherwise, though, see my other post on this subject:
> > unsafePerformIO will perform its action when the variable is
> > accessed, so you can't write a Haskell program which differentiates
> > between what any compiler actually does and running the variable
> > allocations before main.
> If you initialize this "global variable" with a value from a file
> which is changed by main (or over time) then order does matter.
1. Why would you do this? In any case, the solution adopted in C
(initialize the global statically with ``no value'' (0, NULL,
Nothing, etc.) and overwrite it at a fixed point in main or
elsewhere) should be good enough.
2. In any case, my claim is actually:
If a :: IO alpha, for monomorphic alpha, and a's only interaction with
the state consists of either creating new IORefs or accessing IORefs
created by a, then unsafePerformIO's result is unaffected by the order
> I claim unsafePerformIO is very often unsafe
It's always potentially unsafe. However, it is always possible to prove
that a particular application is safe (under sufficiently stringent
conditions, of course).
> - the question is more like if the "level of unsafety" is acceptable
> for a particular application.
There is no "level of unsafety". There is only the level of trust you
put in your proof of satisfaction of unsafePerformIO's proof obligation
and your view of the acceptability of the portability restrictions of