On Mon, May 19, 2014 at 11:28 AM, Bob Hutchison <hutch-li...@recursive.ca>wrote:
> > On May 19, 2014, at 1:44 PM, Ben Wolfson <wolf...@gmail.com> wrote: > > 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. > > > I badly miss the Maybe and Either monads, but would want the syntactic > support Haskell provides (which I can't see will ever be available in > Clojure) > I've been pretty happy with: https://github.com/bwo/monads/blob/master/src/monads/core.clj#L65 > > 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). > > > Which is why I didn't call them atoms :-) There's also a ref in the ST > monad (which is a bells-and-whistles state monad that has fallen into a bit > of disuse since the IO monad appeared) > Well, my point was that IORefs seem to provide in Haskell what atoms provide in Clojure. The refs in ST don't do the the same work because the existential type parameter keeps them from being shared across distinct runST invocations. -- 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.
