> > 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 < bugf...@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 <wqeqwe...@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@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 > > > > >
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
