7 ms·

Why monads have not taken the Common Lisp world by storm (2008)

104 points by platz 13y ago

nathell 13y ago
There's cl-parser-combinators (https://github.com/Ramarren/cl-parser-combinators https://github.com/Ramarren/cl-parser-combinators), which is supposed to aid in writing parsers in a painless, Parsec-like way. I haven't used it, but it may be worth a try.
olenhad 13y ago
For clojure, there's kern (https://github.com/blancas/kern https://github.com/blancas/kern) for parsec style parser combinators. It's quite easy to use. Ironically, I actually understood parser combinators better by reading its wiki (By understood, I mean understood how to _use_ parser combinators). Parsec was initially difficult to grasp because the type system complicated things for me then. I only got Parsec completely after that eureka moment when I finally understood Monads.
- angerman 13y ago
  While not directly monad related. There's also instaparse (https://github.com/engelberg/instaparse https://github.com/engelberg/instaparse) which has also pretty nice presentation. https://www.youtube.com/watch?v=b2AUW6psVcE https://www.youtube.com/watch?v=b2AUW6psVcE 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.
  - mrottenkolber 13y ago
    Also, nobody cares. Since this comment is not even remotely related anymore.
- mrottenkolber 13y ago
  Nobody was talking about Clojure. Do you also have to hijack CL discussions now? Taking over the term "Lisp" wasn't enough?
  - mrottenkolber 13y ago
    Yup downvote me. Because this isn't obviously a CL thread. What a nice display of Clojure propaganda, when in a CL thread, a related library is scored lower than a clojure library.
    - S4M 13y ago
      Why all this hate about Clojure? I didn't downvote you, but I can see why people would, seems olenhad was mentioning a library similar to Parsec in a language that is very related to Common Lisp. There is definitely no need to get carried away.
      - copergi 13y ago
        If there's one thing SLWs hate, it is other SLWs.
        jessaustin 13y ago
        SLW? Single-language... weirdo?
        aerique 13y ago
        Smug Lisp Weenie
        mrottenkolber 13y ago
        Consider the fact that I am probably the only one in this thread who is actually getting paid to write Clojure. And yes Clojure is horrible.
        deleted 13y ago
        [deleted]
        S4M 13y ago
        I am honestly curious what you have against Clojure. I dabbed with CL and Clojure, not as much as I would have liked to, but for me they felt similar. I would be curious to have a list of things that can easily be achieved with CL but not with Clojure.
nnq 13y ago
Let me guess, the 'parser for a reasonably complicated language' was actually a Javascript parser written in CL, more exactly what is today http://marijnhaverbeke.nl/parse-js/ http://marijnhaverbeke.nl/parse-js/ ?
mrottenkolber 13y ago
See http://mr.gy/maintenance/mpc http://mr.gy/maintenance/mpc (self-plug). 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. [1] https://github.com/drewc/smug https://github.com/drewc/smug
kbd 13y ago
Needs a (2008)
dschiptsov 13y ago
Because they make no sense for a dynamic [but strong] typing language?) http://karma-engineering.com/lab/wiki/Monads http://karma-engineering.com/lab/wiki/Monads
- platz 13y ago
  Douglas Crockford seems to think otherwise: http://www.youtube.com/watch?v=b0EF0VTs9Dc http://www.youtube.com/watch?v=b0EF0VTs9Dc
  - copergi 13y ago
    He also gets a lot wrong in that talk, so that doesn't seem like a particularly compelling case.
    - alanning 13y ago
      Could you point out some of the issues you noticed in the talk? (Asking from the point of view of someone curious about monads.)
      - tel 13y ago
        I'm not interested in watching it again, but my impression from the last time is that he's about 3/5ths of the way to "true monad nirvana" if such a thing were a place. There are higher levels above that where we start to really understand the category theoretic and PLT theoretic mechanism of monads, but I think that's truly a different tier.
      - habitue 13y ago
        From watching half of it, he mistakes monads for being a trick to avoid Io, which is not true. Io really does happen in Haskell, it is just contained. Also he mentions types not being necessary to understand monads, but immediately launches into a description of the bind and unit functions by, you guessed it, stating what the types of the function's were and what kinds of things they returned (I.e. the exact thing he said he wouldn't talk about on the previous slide). 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.
Chattered 13y ago
"It appears that in the presence of mutable state, a lot of the advantages of monads become moot." 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.html 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.
- deleted 13y ago
  [deleted]
- zak_mc_kracken 13y ago
  > If you have imperative state then toy uses of the state monad might be overkill 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?
marijn 13y ago
Author here. I am considering putting a "this is ancient, please don't submit it to social linking sites" header on top this. It's appeared on here two times in the past year. It never was a very good article to begin with, and six years later, it just looks lame.
- ScottBurson 13y ago
  I beg to differ. As someone who has not taken the trouble to learn Haskell, but who knows Common Lisp, I find it helpful.
- gus_massa 13y ago
  Don’t worry, no article is perfect. I found this article interesting and maybe I’ll try some of these ideas in Racket. Previous discussions (they have different submitters and a slightly different URL): https://news.ycombinator.com/item?id=6398393 https://news.ycombinator.com/item?id=6398393 (63 points, 221 days ago, 48 comments) https://news.ycombinator.com/item?id=448293 https://news.ycombinator.com/item?id=448293 (33 points, 1918 days ago, 27 comments)

104 points by platz 13y ago

There's cl-parser-combinators (https://github.com/Ramarren/cl-parser-combinators https://github.com/Ramarren/cl-parser-combinators), which is supposed to aid in writing parsers in a painless, Parsec-like way. I haven't used it, but it may be worth a try.

olenhad 13y ago

For clojure, there's kern (https://github.com/blancas/kern https://github.com/blancas/kern) for parsec style parser combinators. It's quite easy to use. Ironically, I actually understood parser combinators better by reading its wiki (By understood, I mean understood how to _use_ parser combinators). Parsec was initially difficult to grasp because the type system complicated things for me then. I only got Parsec completely after that eureka moment when I finally understood Monads.

angerman 13y ago
While not directly monad related. There's also instaparse (https://github.com/engelberg/instaparse https://github.com/engelberg/instaparse) which has also pretty nice presentation. https://www.youtube.com/watch?v=b2AUW6psVcE https://www.youtube.com/watch?v=b2AUW6psVcE 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.
- mrottenkolber 13y ago
  Also, nobody cares. Since this comment is not even remotely related anymore.
mrottenkolber 13y ago
Nobody was talking about Clojure. Do you also have to hijack CL discussions now? Taking over the term "Lisp" wasn't enough?
- mrottenkolber 13y ago
  Yup downvote me. Because this isn't obviously a CL thread. What a nice display of Clojure propaganda, when in a CL thread, a related library is scored lower than a clojure library.
  - S4M 13y ago
    Why all this hate about Clojure? I didn't downvote you, but I can see why people would, seems olenhad was mentioning a library similar to Parsec in a language that is very related to Common Lisp. There is definitely no need to get carried away.
    - copergi 13y ago
      If there's one thing SLWs hate, it is other SLWs.
      - jessaustin 13y ago
        SLW? Single-language... weirdo?
        aerique 13y ago
        Smug Lisp Weenie
      - mrottenkolber 13y ago
        Consider the fact that I am probably the only one in this thread who is actually getting paid to write Clojure. And yes Clojure is horrible.
        deleted 13y ago
        [deleted]
        S4M 13y ago
        I am honestly curious what you have against Clojure. I dabbed with CL and Clojure, not as much as I would have liked to, but for me they felt similar. I would be curious to have a list of things that can easily be achieved with CL but not with Clojure.

nnq 13y ago

Let me guess, the 'parser for a reasonably complicated language' was actually a Javascript parser written in CL, more exactly what is today http://marijnhaverbeke.nl/parse-js/ http://marijnhaverbeke.nl/parse-js/ ?

mrottenkolber 13y ago

See http://mr.gy/maintenance/mpc http://mr.gy/maintenance/mpc (self-plug). 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. [1] https://github.com/drewc/smug https://github.com/drewc/smug

kbd 13y ago

Needs a (2008)

dschiptsov 13y ago

Because they make no sense for a dynamic [but strong] typing language?) http://karma-engineering.com/lab/wiki/Monads http://karma-engineering.com/lab/wiki/Monads

platz 13y ago
Douglas Crockford seems to think otherwise: http://www.youtube.com/watch?v=b0EF0VTs9Dc http://www.youtube.com/watch?v=b0EF0VTs9Dc
- copergi 13y ago
  He also gets a lot wrong in that talk, so that doesn't seem like a particularly compelling case.
  - alanning 13y ago
    Could you point out some of the issues you noticed in the talk? (Asking from the point of view of someone curious about monads.)
    - tel 13y ago
      I'm not interested in watching it again, but my impression from the last time is that he's about 3/5ths of the way to "true monad nirvana" if such a thing were a place. There are higher levels above that where we start to really understand the category theoretic and PLT theoretic mechanism of monads, but I think that's truly a different tier.
    - habitue 13y ago
      From watching half of it, he mistakes monads for being a trick to avoid Io, which is not true. Io really does happen in Haskell, it is just contained. Also he mentions types not being necessary to understand monads, but immediately launches into a description of the bind and unit functions by, you guessed it, stating what the types of the function's were and what kinds of things they returned (I.e. the exact thing he said he wouldn't talk about on the previous slide). 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.

Chattered 13y ago

"It appears that in the presence of mutable state, a lot of the advantages of monads become moot." 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.html 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.

deleted 13y ago
[deleted]
zak_mc_kracken 13y ago
> If you have imperative state then toy uses of the state monad might be overkill 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?

marijn 13y ago

Author here. I am considering putting a "this is ancient, please don't submit it to social linking sites" header on top this. It's appeared on here two times in the past year. It never was a very good article to begin with, and six years later, it just looks lame.

ScottBurson 13y ago
I beg to differ. As someone who has not taken the trouble to learn Haskell, but who knows Common Lisp, I find it helpful.
gus_massa 13y ago
Don’t worry, no article is perfect. I found this article interesting and maybe I’ll try some of these ideas in Racket. Previous discussions (they have different submitters and a slightly different URL): https://news.ycombinator.com/item?id=6398393 https://news.ycombinator.com/item?id=6398393 (63 points, 221 days ago, 48 comments) https://news.ycombinator.com/item?id=448293 https://news.ycombinator.com/item?id=448293 (33 points, 1918 days ago, 27 comments)