Re: [Haskell-cafe] A question about State Monad and Monad in general

Sorry, the previous code does not compile. It should be: 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) print_pixels pixels in "print_pixels" "mapM" has been changed to "mapM_" -deech On Mon, Jul 19, 2010 at 11:36 AM, aditya siram wrote:

Do you want a solution like this?

import Data.IORef

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)  print_pixels pixels

GHCI Output: *Main> test_replace (1,2,3) (10,11,12) (7,8,9) [(),(),()]

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 mutated in-place. -deech

On Mon, Jul 19, 2010 at 4:07 AM, C K Kashyap 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 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 wrote:

...

C K Kashyap 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.

-k -- If I haven't seen further, it is by standing in the footprints of giants _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

-- Regards, Kashyap

-- Regards, Kashyap

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe