Thanks Aditya...I think that is what I am looking for. On Mon, Jul 19, 2010 at 10:40 PM, aditya siram <aditya.si...@gmail.com>wrote:
> 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 > >> > >> > > > -- Regards, Kashyap
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe