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

[aditya siram]

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 <aditya.siram at gmail.com> 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 <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.
>>>>
>>>> -k
>>>> --
>>>> If I haven't seen further, it is by standing in the footprints of giants
>>>> _______________________________________________
>>>> Haskell-Cafe mailing list
>>>> Haskell-Cafe at haskell.org
>>>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>>
>>>
>>>
>>> --
>>> Regards,
>>> Kashyap
>>
>>
>>
>> --
>> Regards,
>> Kashyap
>>
>> _______________________________________________
>> Haskell-Cafe mailing list
>> Haskell-Cafe at haskell.org
>> http://www.haskell.org/mailman/listinfo/haskell-cafe
>>
>>
>