[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