[Haskell-cafe] |> vs. $ (was: request for code review)

[Jared Updike]

> Dude, that was a friggin' awesome email!  I'm trying to figure out how
> I can just copy it wholesale into the article ;)

Use what you need. Share and share alike.

> I've been struggling
> with Haskell for long enough that my knowledge is now snowballing
> downhill.

I think I experienced that too. I like how Haskell is about the
concepts (even things you didn't know you were already doing
implicitly) and the language is just a very transparent vehicle for
manipulating them. Haskell has really taught me a lot and helped me
think a lot clearer---but now I think in Haskell! The danger is that
since I've taken the red "Haskell" pill I have a hard time looking at
the imperative world the same way. I have to resist trying to cram all
these elegant approaches into a system that can't support them and
instead program like a normal person. (The good news is that many
languages are slowly soaking up features, e.g. C# delegates are
higher-order functions and anonymous delegates are lambdas, C# 3.0
will have some kind of type inference, etc. but these features are
many decades old.)

> Everything you said made sense 100%.

To add a few more comments to this: in Haskell you don't overload the
semicolon, instead you overload >>= ("bind") and create a new
typeclass with this function (as well as a function called "return",
where these two functions obey certain laws that keep things kosher,
i.e. "return" is the identity, >>= is associative, and they interact
as you would expect). It just so happens that the semicolons (or
newlines) in do blocks get converted into >>=s and lambdas to scope
your variables over the rest of your actions.

The reason monads are cool and magical is that now that we've made
this sequencing explicit in the type, we can swap out the machinery
(what type of implicit state we're passing around or even the >>=
function itself) and change a minimal amount of code, i.e. nothing...
except adding code to use the new functionality (if all goes well). We
can now get continuation passing, or true mutable variables (e.g.
IORef), or a simple sort of non-determinism (e.g. List as a monad), or
failure (Maybe) or exception handling, or any number of behaviors (or
combinations) by changing the monad.

BTW the original discussion was about composing functions and I gotta
say since C programmers don't really think in terms of "f . g x = f (g
x)" anyways, and since writing code in the order it executes is
natural (think Python   str.replace('\r', '').split('\n')  ), I think
the idea of explaining |> as a pipe is pretty cool. There might be a
little too much overhead in explaining things if you drop the M-bomb
(monads), but if you can make and keep monads clear and simple and use
them there, you will have accomplished a great feat (and analogies
like Unix pipes are a good thing). I'm curious to see how this
evolves.

Good luck.
  Jared.
--
http://www.updike.org/~jared/
reverse ")-:"