Hi all,

When I went up and talked about the "bind" operator (>>=), there was some ambiguity regarding what it does.

The true nature of the "bind"operator is this; move along the line of code to be executed, passing the result of the former function to the latter function, and so on until you reach the end of the line of code. Once it notices that a function will return Nothing, then the whole line of code will return Nothing. An example would be: Just 1 >>= \x -> return (x+1) will output Just 2 whereas Just 1 >>= return Nothing will output Nothing. Essentially, it's just a glorified form of function composition.

A noteworthy fact that I'd like to share is that Haskell reads [] as Nothing, so if a function that returns an empty list is bound to another function, the result will always be an empty list.

You might be asking yourself, "Well, if the bind operator is just function composition, then why even use it?" The answer lies within the context of the values passed into it. The "bind" operator will preserve the context of the values throughout the line of code. How is this useful? Well, this ensures that throughout the line of code, whatever you pass in is what you will get back out in terms of the type of the value versus the value itself, which goes back to Haskell being a pure functional language.

Another thing I wanted to talk about today was the >> operator, which is simply just an alias for >>= \_ ->. Essentially, the general operation is still a function composition, but what it's doing is that the former function in the line of code is still passing the result into the latter function, but the latter function is not considering the value of the result of the former function, only the context behind the value. I can talk about this more if I'm given the opportunity to.

If there are questions, comments, or corrections, then please feel free to reply. Thanks in advance!

-George Chan

P.S. I apologize about the late post, I had a senior design meeting to go to today.

EDIT: The source I used is from the Learn You a Haskell book in Chapter 12, but I might have interpreted it wrong. If that is the case, then I would very much appreciate if someone can help me understand where I went wrong and how it should be. Thanks in advance.