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.si...@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 <ckkash...@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 <ckkash...@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 <ke...@malde.org> wrote: >>>> >>>> C K Kashyap <ckkash...@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@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 >> >> > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
