Hi Peter,

I'm glad to see you're getting into the Reactive code!

As a complement to Luke's answer:

I think readIVar is an exception to the usual guidelines below.  The point of the IVar type is that it can get written at most once, so any read will yield the same value.  It doesn't matter in this case whether the readMVar computation is duplicated.  It always has to yield the same result, namely the only value that has been or will be written to the MVar, or bottom if no value ever gets written.  As Luke mentioned, the IVar interface does not allow takeMVar to be called, except via readMVar, which replaces the value after reading.

  - Conal

2008/11/20 Peter Verswyvelen <bugfact@gmail.com>
When I was browsing the GHC documentation, I came across the following:

If the I/O computation wrapped in unsafePerformIO performs side effects, then the relative order in which those side effects take place (relative to the main I/O trunk, or other calls to unsafePerformIO) is indeterminate. You have to be careful when writing and compiling modules that use unsafePerformIO:
  • Use {-# NOINLINE foo #-} as a pragma on any function foo that calls unsafePerformIO. If the call is inlined, the I/O may be performed more than once.
  • Use the compiler flag -fno-cse to prevent common sub-expression elimination being performed on the module, which might combine two side effects that were meant to be separate. A good example is using multiple global variables (like test in the example below).
  • Make sure that the either you switch off let-floating, or that the call to unsafePerformIO cannot float outside a lambda. For example, if you say: f x = unsafePerformIO (newIORef []) you may get only one reference cell shared between all calls to f. Better would be f x = unsafePerformIO (newIORef [x]) because now it can't float outside the lambda.
Now in Reactive, in e.g. the internal IVar.hs module, I see

readIVar :: IVar a -> a
readIVar (IVar v) = unsafePerformIO $ readMVar v

At first sight this function is not following all the rules described above. Could this cause problems?

Cheers,
Peter
  

 

_______________________________________________
Reactive mailing list
Reactive@haskell.org
http://www.haskell.org/mailman/listinfo/reactive