Why monads have not taken the Common Lisp world by storm (2008)
marijnhaverbeke.nl
marijnhaverbeke.nl
If you have imperative state then toy uses of the state monad might be overkill. But, for example, in a parser, imperative state is unlikely to help you. Here, you want state to be discarded at failure and old states restored by backtracking. The execution paths are highly complicated (as they always are when you are working with what are effectively continuations), and trying to reason about these paths in the face of imperative update isn't easy, and is likely to lead to weird bugs.
Toy examples are not generally going to help you appreciate monads, and I think there's a fourth requirement to make them work in a language: you need a powerful type-system. I'd say that monads haven't taken F# by storm because F# isn't powerful enough to type-check a library for arbitrary monads. And you want that, because when it comes to reasoning about code using such libraries and then applying it to a monad assembled from a stack of several other monads, you really want your type-checker around.
Ocaml's type-system is powerful enough for this, and I still reach for my monad library when writing Ocaml code. It's syntactically heavier than Haskell, but not too painful. The solution is to make all your monads into modules, which would be a bit like making every monad a dictionary and passing it around explicitly. This is basically what Haskell ends up doing with type-classes anyway, and what Gabriel Gonzalez has suggested one do explicitly:
http://www.haskellforall.com/2012/05/scrap-your-type-classes...
If you follow this approach, Common Lisp and any other language can pull it off by making all monads into dictionaries. All you lose is the type-checking.
What's imperative state? These are two very different concepts.
Both functional and imperative code can be manipulating state, and that state can be either mutable or immutable.
Haskell is often considered to be both a functional and an imperative language (see how linking do statements works).
I'm guessing you meant to say "mutable state" above?
If I'm working in code where the operational semantics is not fully defined or difficult to reason about, I might find myself reaching for the state monad, regardless of whether my language supports imperative state (such as with Ocaml). I brought up back-tracking parsers as an example.
I'd actually go so far as to say Haskell is quite multi-paradigm but only the FP side comes close enough to Haskell's "purity" as to make a community translation. I'd be quite willing to say that Haskell has a fantastically correct if slightly difficult to use object system.
It just doesn't quack anything at all like Smalltalk or Java's.
Imperative, to me, means a language structured over the execution of statements in order. I think that's a fairly common definition.
Chaining monadic binds with a `do` is the textbook example of imperative programming (it's actually the very reason why the keyword 'do' was chosen for syntactic sugar, because it captures perfectly the imperative aspect: "do this and in this order").
You seem to think it's a bad word but I really don't understand that. Haskell is both functional and imperative, there's really nothing wrong about it.
[1] http://research.microsoft.com/en-us/um/people/simonpj/Papers...
Although the specific problem of state-with-backtracking would be more idiomatically solved with dynamic binding.
If I was more skilled with monads, I might go directly to the ideal monadic solution... but I suspect I wouldn't have ideas that didn't fit well with monads in the first place. That is, (I fear) thinking in monads would restrict the breath of approaches that would come to mind... Disclaimer: because I'm not skilled in monads, I don't really know.
This comes to play in parsers because a lot of their challenge is in properly piping around the recursive-backtracking state parts. Using monads you just create a semantic world where this recursive backtracking bit is built into the "nature" of state in your particular monad.
Previous discussions (they have different submitters and a slightly different URL):
https://news.ycombinator.com/item?id=6398393 (63 points, 221 days ago, 48 comments)
https://news.ycombinator.com/item?id=448293 (33 points, 1918 days ago, 27 comments)
I just wanted to leave this here as if it hadn't been for twitter and the presentation, I would likely never have known about it.
What a nice display of Clojure propaganda, when in a CL thread, a related library is scored lower than a clojure library.
"Clojure is predominantly a functional programming language, and features a rich set of immutable, persistent data structures. When mutable state is needed, Clojure offers a software transactional memory system and reactive Agent system that ensure clean, correct, multithreaded designs."
That being said, I liked his reworking of bind to be a method on an object. I agree monadic computation is tedious to read when you don't have an infix bind operator, and his trick of turning bind into a method solves that pretty well in a language like JavaScript.
I think he's probably overstating the case that what he calls ajax chaining is always monadic (but what most of us who didn't write a competing library would call jquery style method chaining). I would guess most implementations of this kind of APIs do not adhere to the monad laws.
The reason why they have not taken CL… wait, for starters why must they? Haskell is far far more advanced in the ideas of abstaction (strong static typing, — so it just needs to be). Experienced lispers will put yet another DSL, experienced haskellers won't, for “it's just monoid in the category of endofunctors, duh” (haskell forklore)
A friendly fork of Drew Crampsie's Smug¹.
MPC is a monadic parser combinators library. It provides a toolbox of predefined parsers, facilities for error handling and parses arrays, streams and lists.