Hi,
I've been playing with some haskell bindings which basically bind C
procedures in the IO monad. To write 'interesting' programs, you often
need to manage your own state in addition to the implicit IO state.
I have been allocating references with newIORef and then passing them
around all my functions. But having to thread a parameter through all
your functions is inconvenient (and fragile). I can see the solution to
this problem in layering a state monad over the IO monad, and I can
just about grok the syntax I need to use StateT, with a nice
encapsulated environment record type and nice selector functions to use
with gets. Now of course I don't even need to use IORefs any more since
I can be more explicit and precise about my state and how it's
manipulated. (this is potential even a useful feature, since I can step
back to earlier time points just by saving the state, etc.)
Unfortunately, it's not going to work. It's not going to work because
some of the procedures take callbacks, and the callbacks are values of
type IO (). I can see two solutions to this:
a) revert to using an IORef, and use lexical scoping to define my
callbacks in a location such that the reference to the environment is
in scope. This will work, but it's just not convenient to define all
your functions inside another function so you can do a lexical scoping
trick...
b) write the callbacks as values of type
StateT Env IO ()
and then use the following 'environment binder'
bindEnv env s = do { x <- readIORef env ; s' <- execStateT s x;
writeIORef env s'}
when I pass them to a callback. (which works fine as long as I have
used lexical scoping to make sure env is visible at the binding site)
Is this the right approach? Is there a better one?
From the library perspective, would it be cool if library callback
routines, which currently have a type like
addCallback :: IO() -> IO()
could be given the type
addCallback :: MonadIO() -> IO()
So that they'll let you add callbacks for any monad layered over IO. Or
doesn't this idea work?
Jules