On Tue, Sep 02, 2008 at 10:10:31AM +0100, Sittampalam, Ganesh wrote: > > > Contrived example follows: > > > > > module Module1 (mod1) where > > > import Module2 > > > > > > glob1 :: IORef Int > > > glob1 <- mod2 >>= newIORef > > > > > mod1 :: IO Int > > > mod1 = readIORef glob1 > > > > > module Module2 (mod2) where > > > > import Module1 > > > > glob2 :: IORef Int > > > glob2 <- mod1 >>= newIORef > > > > > mod2 :: IO Int > > > mod2 = readIORef glob2 > > > This is illegal because you're only allowed to use ACIO > > in top level <- bindings and readIORef isn't (and clearly > > could not be) ACIO. > > (made a couple of changes to quoted example; added import > statements and explicit export lists) > > Even though I never call writeIORef on glob1 or glob2, and > can change the example as above so we don't export them, so > it's impossible to ever do so? > > As an alternative, consider > > module Module1 (mod1) where > import Module2 > > glob1 :: Int > glob1 <- return $! mod2 > > mod1 :: Int > mod1 = glob1 > > module Module2 (mod2) where > > import Module1 > > glob2 :: Int > glob2 <- return $! mod1 > > mod2 :: Int > mod2 = glob2 > > Even more artificial, of course. > > Arguably both of these cases are not ACIO simply because > of the non-termination effects, but it's not obvious to > me how you tell just by looking at either one's code together > with the declared API of the other. Is anything strict > automatically forbidden by ACIO?
Isn't this just a pure infinite loop? Why is it a problem that ACIO allows you the flexibility that's present in any pure code? David _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
