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

[C K Kashyap]

Thanks Aditya...I think that is what I am looking for.

On Mon, Jul 19, 2010 at 10:40 PM, aditya siram <aditya.siram at 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.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
> >>
> >>
> >
>



-- 
Regards,
Kashyap
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20100720/8914d823/attachment.html