[Haskell-cafe] Top Level <-

David Roundy droundy at darcs.net
Tue Sep 2 11:02:40 EDT 2008


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


More information about the Haskell-Cafe mailing list