# some insights into functional programming

5 messages
Open this post in threaded view
|

## some insights into functional programming

 I'm starting to figure out a few things that I didn't "get" about functional programming and monads. I wanted to explain them. I'm not looking for a particular response to this post, other than any elaboration that seems natural. There is an exercise here working with the trivial monad W: Write a function g :: W a ->  W a -> W a such that g (W x) (W y) = W (x+y) except don't use pattern matching, but >>= instead. The answer is g mx my = mx >>= (\x -> my >>= \y -> W (x+y)) There are a couple things here that threw me off. One is that I didn't expect 'my' to be available inside the first lambda. I somehow thought of lambda as isolated, sealed-off from the rest of the universe. But they aren't. I believe this is the concept of closures, or related to it? Secondly, I didn't expect >>= to be available inside the lambda. This is related to the mistaken conception of >>= as a procedural statement rather than an expression. In Python, where I have previously encountered lambdas, no statements are allowed inside lambdas. Of course, >>= is actually an expression and you can put any expression to the right of a lambda ->. Maybe these are typical beginner misconceptions, or maybe they have more to do with coming from Python and complete beginners actually find it more natural. Mike
Open this post in threaded view
|

## some insights into functional programming

 Michael, > g mx my = mx >>= (\x -> my >>= \y -> W (x+y)) > > There are a couple things here that threw me off. One is that I didn't   > expect 'my' to be available inside the first lambda. I somehow thought of > lambda as isolated, sealed-off from the rest of the universe. But they   > aren't. I believe this is the concept of closures, or related to it? Yes!  You're spot on; 'my' is available precisely because closures encapsulate the part of the surrounding environment that's referenced by bound variables. > Secondly, I didn't expect >>= to be available inside the lambda. This is   > related to the mistaken conception of >>= as a procedural statement > rather than an expression. In Python, where I have previously encountered > lambdas, no statements are allowed inside lambdas. Of course, >>= is > actually an expression and you can put any expression to the right of a > lambda ->. With all due respect to Python (a language I like but no longer use), it's no place to develop any intuition about lambdas. Python's lambda is an attempt to incorporate some of the syntactic benefit of anonymous functions while refusing them any real meaning or importance. > Maybe these are typical beginner misconceptions, or maybe they have more > to do with coming from Python and complete beginners actually find it > more natural. As you can probably guess, I think it's more the latter.  But I can't say first-hand because I dabbled in dozens of languages before Haskell, and I got my intuition for lambda from scheme.  I wish I'd learned them in Haskell though, because with purity they're more elegant. Cheers, John
Open this post in threaded view
|