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.
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
