Re: [Haskell] threading mutable state through callbacks
its almost commutative
Does that have something to do with splitting the supply?
newIORef
why not use 'newSTRef' and use the ST monad... Keean.
On 13 Oct 2004, at 13:14, MR K P SCHUPKE wrote:
its almost commutative
Does that have something to do with splitting the supply?
That is an approach to getting unique values, I think.
newIORef
why not use 'newSTRef' and use the ST monad...
In the context of my original question, the answer is that the control flow of the program passes through external libraries ('C' code, if you like to think of it that way), and the callbacks in question have signature IO(), so they are constrained to store all their state in the IO monad. Were it not for this problem, the ST monad would indeed seem more elegant. And some explicit state monad with a nicely designed set of state for your application is probably more elegant still... but unfortunately that isn't possibly. Unless its possible to arrange haskell FFI bindings to have types in MonadIO rather than IO... (a question which I asked earlier but no one has answered). Juels
There are stToIO and ioToST sunctions though (ioToST is unsafe)... Keean Jules Bean wrote:
On 13 Oct 2004, at 13:14, MR K P SCHUPKE wrote:
its almost commutative
Does that have something to do with splitting the supply?
That is an approach to getting unique values, I think.
newIORef
why not use 'newSTRef' and use the ST monad...
In the context of my original question, the answer is that the control flow of the program passes through external libraries ('C' code, if you like to think of it that way), and the callbacks in question have signature IO(), so they are constrained to store all their state in the IO monad.
Were it not for this problem, the ST monad would indeed seem more elegant. And some explicit state monad with a nicely designed set of state for your application is probably more elegant still... but unfortunately that isn't possibly. Unless its possible to arrange haskell FFI bindings to have types in MonadIO rather than IO... (a question which I asked earlier but no one has answered).
Juels
Jules Bean <jules@jellybean.co.uk> writes:
Unless its possible to arrange haskell FFI bindings to have types in MonadIO rather than IO...
MonadIO is a class, not a type. Anyway, it's conceptually impossible to wrap a computation of an arbitrary monad in the MonadIO class into IO. It's not a technical difficulty, it just does not make sense. It's similar to asking for a non-trivial function of type Monad m => m a -> a. Unless you mean something else. -- __("< Marcin Kowalczyk \__/ qrczak@knm.org.pl ^^ http://qrnik.knm.org.pl/~qrczak/
participants (4)
-
Jules Bean -
Keean Schupke -
Marcin 'Qrczak' Kowalczyk -
MR K P SCHUPKE