I wouldn't say that I *often* find myself reaching for monads, or the state monad in particular, but I certainly have found them useful on occasion (and would have sometimes refrained from using them where I'd naturally lean to doing so solely to avoid creating an dependency). For instance, whenever there's a couple of functions that return either a success value or an error message that have to be threaded together---an error monad to do the plumbing makes this a lot nicer.
We've got a library at ReadyForZero for walking though json and xml structures and doing transformations based on the values found there, or a bit of configuration, using a combined reader-writer-state monad, and a bunch of code that uses it. The state that's held is actually just a zipper into the structure, the configuration at this point is only a keyword, and the writer log holds reports of unexpected values. This could all be done with other machinery---pass the zipper around directly (or hold it in an atom), pass the log around directly (or hold it in an atom), use a dynamic variable + binding for the configuration (since the reader monad amounts to that anyway). However, I think the monadic code is easier to work with, partly because nothing does need to be managed or passed around explicitly (so it's easier to put together lots of little pieces), and partly because it enables the use of generic tools. Also, traversing the the structures has a fairly imperative feel---go here, go there, do this transformation---with occasional variable binding, and the macro for monadic computations the monad library we're using provides makes expressing that fairly convenient. (Though I may be biased, since I wrote it.) It's true that there doesn't seem to be much need for introducing a monad library and using the state monad if you *only* had the state monad, since Clojure has other ways to deal with mutation (incidentally, I don't think it's true to say that Haskell only has refs, not atoms; there are functions to modify IORefs, which live outside the STM system, atomically). On Fri, May 16, 2014 at 5:49 PM, Julian <juliangam...@gmail.com> wrote: > A quick shoutout to the Clojure Community - thanks for the way you've all > contributed to make my life (mentally) richer. > > James Reeves (author of Compojure and many other wonderful libraries) made > this interesting comment on Hacker News: > > Clojure has libraries that implement monads, but these aren't often > used for threading state. I can't quite place my finger on why, but in > Clojure I rarely find myself reaching for something like the state monad, > as I would in Haskell. > > >Clojure tends to view mutability as a concurrency problem, and the tools > it provides to deal with mutability, such as atoms, refs, agents, channels > and so forth, are not mechanisms to avoid mutation, as to provide various > guarantees that restrict it in some fashion. > > >It might be that in the cases where I'd use a state monad in Haskell, in > Clojure I might instead use an atom. They're in no way equivalent, but they > have some overlapping use-cases. > > https://news.ycombinator.com/item?id=7751424 > > My question is - have other Clojure/Haskell programmers had this > experience? (ie "I rarely find myself reaching for something like the > state monad"). I'm interested to hear if so, and why. > > JG > > PS If this post is unhelpful, could be worded better - please let me know. > I'm asking out of curiosity, not with intent to troll. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Ben Wolfson "Human kind has used its intelligence to vary the flavour of drinks, which may be sweet, aromatic, fermented or spirit-based. ... Family and social life also offer numerous other occasions to consume drinks for pleasure." [Larousse, "Drink" entry] -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
