[Haskell-cafe] Re: Monads aren't evil

[Peter Verswyvelen]

>
> For example, which of these is easier to read?
>
> f,g :: Int -> [Int]
>
> h1 :: Int -> [Int]
> h1 x = do
>    fx <- f x
>    gx <- g x
>    return (fx + gx)
>
> h2 :: Int -> [Int]
> h2 x = (+) <$> f x <*> g x
>
> h3 :: Int -> [Int]
> h3 x = f x + g x   -- not legal, of course, but wouldn't it be nice if it
> was?
>

Yes, all that lifting is something that takes away lot of the beauty and
simplicity of Haskell, but as far as my limited knowledge goes, I don't
think this problem is easily solved :)

Anyway, for your particular example, for newbies I guess the clearest would
be:

h0 x = [ fx+gx | fx <- f x, gx <- g x ]

since one must recognize that a list monad exists and what it does...

Now, for binary operators, Thomas Davie made a nice pair of combinators on
Hackage (InfixApplicative) that would allow this to become:

h3 x = f x <^(+)^> g x

But in general, I guess you have a good point...




>
> Of course this raises problems of order of evaluation, etc, but as
> long as such things were well-defined, that seems fine.  If you want
> finer control, you can always go back to more verbose syntax.  These
> cases are dominated by the cases where you simply don't care!
>
> This said, I don't want to sound overly negative; all of this pain is
> *worth* the correctness guarantees that I get when writing in Haskell.
>  I just wish I could get the same guarantees with less pain!
>
>  -- ryan
>
>
> 2009/1/10 Peter Verswyvelen < bugfact at gmail.com>:
> > Related to this issue, I have a question here.
> > I might  be wrong, but it seems to me that some Haskellers don't like
> > writing monads (with do notation) or arrows (with proc sugar) because of
> the
> > fact they have to abandon the typical applicative syntax, which is so
> close
> > to the beautiful lambda calculus core. Or is it maybe because some people
> > choose monads were the less linear applicative style could be used
> instead,
> > so the choice of monads is not always appropriate.
> > Haskell is full of little hardcoded syntax extensions: list notation
> > syntactic, list comprehensions, and even operator precedence that reduces
> > the need for parentheses, etc...
> >
> > Of course IMHO the syntactic sugar is needed, e.g. a Yampa game written
> > without the arrows syntax would be incomprehensible for the average
> > programmer. But one could claim that this syntactic sugar hides what is
> > really going on under the hood, so for newcomers these extensions might
> make
> > it harder. It could also feel like a hack, a failure to keep things as
> > simple as possible yet elegant.
> > Some people I talked with like that about the Scheme/ & LISP languages:
> the
> > syntax remains ultimately close to the core, with very little hardcoded
> > syntactic extensions. And when one wants to add syntactic extensions, one
> > uses syntactic macros.
> > I'm not sure what others feel about the hardcoded syntax extensions in
> > Haskell...
> >
> > Personally I'm not that much of a purist, I'm an old school hacker that
> > mainly needs to get the job done. I like the syntax extensions in Haskell
> > (and even C#/F# ;) because they let me write code shorter and clearer...
> > On Fri, Jan 9, 2009 at 4:07 AM, Neal Alexander <wqeqweuqy at hotmail.com>
> > wrote:
> >>
> >> Ertugrul Soeylemez wrote:
> >>>
> >>> Hello fellow Haskellers,
> >>>
> >>> When I read questions from Haskell beginners, it somehow seems like
> they
> >>> try to avoid monads and view them as a last resort, if there is no easy
> >>> non-monadic way.  I'm really sure that the cause for this is that most
> >>> tutorials deal with monads very sparingly and mostly in the context of
> >>> input/output.  Also usually monads are associated with the do-notation,
> >>> which makes them appear even more special, although there is really
> >>> nothing special about them.
> >>>
> >>
> >> Yea, i was the same way when i started learning Haskell. I understood
> how
> >> Monads worked, and what the motivation was for them, but not why i would
> >> want to restructure code to use them in specific instances.
> >>
> >> "Why should i care about monads when i can use Arrows or (.)" was also a
> >> factor.
> >>
> >> Its kinda like getting advice from an adult as a child. You have no
> >> particular reason to distrust the advice, but the value of it doesn't
> set in
> >> until something happens to you first hand to verify it.
> >>
> >> For me the turning point was writing some code that needed to handle
> >> running code locally/remotely in a transparent manner.
> >>
> >> Maybe having a list of real-world usage scenarios or exercises on the
> wiki
> >> may help.
> >>
> >> ______________________________ _________________
> >> Haskell-Cafe mailing list
> >> Haskell-Cafe at haskell.org
> >> http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090110/6a970569/attachment.htm