[Haskell-cafe] Current situation regarding global IORefs

Brian Hulley brianh at metamilk.com
Fri Apr 21 16:51:03 EDT 2006


Robert Dockins wrote:
> Are you compiling with -fglasgow-exts?  You're relying on generalized
> newtype deriving, which is a GHC extension.
>
> http://www.haskell.org/ghc/docs/latest/html/users_guide/type-
> extensions.html#newtype-deriving
>
> If that's not it, what's the error you are getting?

'MonadState does not have arity 1'
(I see now from the docs and from Cale's clause below that the instance 
declaration would be

        instance MonadState MState ManagerM where ...

hence the need for (MonadState MState) to be written in the deriving clause)

Cale Gibbard wrote:
> try deriving (Monad, MonadIO, MonadState MState) -- I find that
> newtype deriving doesn't like guessing at other class parameters, even
> with the fundeps there.

Thanks. The other compilation error was caused by the fact that newtype 
deriving doesn't work in a hs-boot file. I had Control and ManagerM defined 
in different modules, but when I just merged these into one module, and used 
Cale's deriving clause, everything now works..

(Perhaps it doesn't really matter about type/newtype in this case anyway 
since MState is hidden)

>[suggestions about ReaderT]

I think I'll stick with an immutable state record for the moment since there 
does not seem to be a clear advantage one way or the other, and AFAIK ghc 
6.4.2 at the moment does not use a write barrier for IORefs so every 
intergenerational garbage collection follows every IORef in existence which 
could slow things down for a large GUI with individual IORefs for each state 
component.

Robert Dockins wrote:
> Sometimes I also think it would be nice if all the standard lib
> functions with IO types would instead take arbitrary MonadIO types,
> so you could avoid having to write down liftIO all the time....

Thanks for the suggestion - it is certainly a lot better to write liftIO 
inside my FFI wrappers than each time I use these functions elsewhere.

Thanks, Brian. 



More information about the Haskell-Cafe mailing list