[Haskell-cafe] A question about State Monad and Monad in general
aditya.siram at gmail.com
Mon Jul 19 12:36:26 EDT 2010
Do you want a solution like this?
replace :: Int -> [IORef (Int,Int,Int)] -> (Int,Int,Int) -> IO ()
replace index pixels new_val = do
old_val <- return $ pixels !! index
writeIORef old_val new_val
print_pixels = mapM (\p -> readIORef p >>= print)
test_data :: [(Int,Int,Int)]
test_data = [(1,2,3),(4,5,6),(7,8,9)]
test_replace :: IO ()
test_replace = do
pixels <- mapM (newIORef) test_data
replace 1 pixels (10,11,12)
This code takes a list of pixels and replaces the second pixel with
the given value. In this case every pixel is of type IORef which is
On Mon, Jul 19, 2010 at 4:07 AM, C K Kashyap <ckkashyap at gmail.com> wrote:
> Also, Claude ... If I am correct, in your example, there is no in-place
> replacement happening.
> On Mon, Jul 19, 2010 at 2:36 PM, C K Kashyap <ckkashyap at gmail.com> wrote:
>> Okay...I think I am beginning to understand.
>> Is it right to assume that "magic" is backed by FFI and cannot be done in
>> "pure" Haskell?
>> On Mon, Jul 19, 2010 at 1:47 PM, Ketil Malde <ketil at malde.org> wrote:
>>> C K Kashyap <ckkashyap at gmail.com> writes:
>>> > I looked at State Monad yesterday and this question popped into my
>>> > mind.
>>> > From what I gather State Monad essentially allows the use of Haskell's
>>> > do
>>> > notation to "invisibly" pass around a state. So, does the use of
>>> > Monadic
>>> > style fetch us more than syntactic convenience?
>>> At it's heart, monads are "just" syntactic convenience, but like many
>>> other syntactic conveniences, allows you to structure your code better.
>>> Thus it's more about programmer efficiency than program efficiency.
>>> (The "do notation" is syntactic sugar for >>= and >>).
>>> > Again, if I understand correctly, in Mutable Arrays also, is anything
>>> > getting modified in place really? If not, what is the real reason for
>>> > better
>>> > efficiency?
>>> STArray and IOArrays are "magic", and uses monads to ensure a sequence
>>> of execution to allow (and implement) in-place modification. So this
>>> gives you better performance in many cases. Don't expect this from
>>> generic monads.
>>> If I haven't seen further, it is by standing in the footprints of giants
>>> Haskell-Cafe mailing list
>>> Haskell-Cafe at haskell.org
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe