On May 16, 2014, at 8: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. >
I'm perhaps an atypical specimen (and I'm not what I'd call an expert Haskell programmer) but... I've written a fairly substantial prototype in Haskell (maybe 25k sloc, whatever that means) that made heavy use of the state monad. I've re-written the same application in Clojure and it never, even once, occurred to me to use the state monad. As James Reeves pointed out, Clojure programmers normally use atoms or refs to manage this kind of state. Looking at my two code bases you'd notice that the state monad would have been replaced in Clojure by a bunch of refs and atoms. If the state had been less complex and the application less concurrent I'd have used a single atom. In Haskell you'd not be able to use this technique nearly as frequently, if at all, and certainly not in the same way. Please excuse the imprecision in the following... In Haskell, all IO is marked in the type signatures, and so if you want to perform any IO you have to carry the IO monad with you (IO appears in your type signature) into all 'sub' computations. The IO monad exists at the top level of your program, and so must be 'carried' all the way from the top level, you can't just suddenly start using IO deep within some computation. And this is exactly what you want in Haskell -- it's a *good* thing. In Clojure you can perform IO wherever you wish, and in Clojure this is exactly what you want, and is also a *good* thing. Haskell's STM transactions can be thought of as a form of IO action (like reading a file is an IO action) that modify refs (there are no atoms in Haskell, only refs). A transaction must be started in the IO monad and then, like IO, the STM monad is 'carried' in type signatures through all intervening computations that could take part in the transaction. The STM type/monad 'blocks' the IO type/monad (you can't do other IO actions if you might take part in an STM transaction (IO action), this is an effect of, and enforced by, Haskell's type system (i.e. it's a compilation not a runtime error)). In Clojure the STM isn't part of the IO system, and you can start or take part in a transaction anywhere you want to, even nest dosyncs within a single transaction, and intermingle transactional code with IO (no matter how bad an idea that is). That's a lot of talk to get to the point that using the STM has an insignificant impact on the structure of your Clojure programs, while in Haskell the impact is huge (of course, it's possible to argue that that's a *good* thing). In Haskell the state monad is pretty flexible, well supported by the language, and allows you to sidestep a lot of this impact (for one thing, you can introduce it anywhere). In Clojure the state monad would buy you nothing (in my opinion) while using it would have an impact on your programs structure. In Haskell there are forces pushing you to use the state monad, while in Clojure there are forces pushing you away from the state monad. In my opinion. ---- I've 'simplified' my explanation, and obscured some of the actual issues/powers/advantages of Haskell's type system. For example, I hand-wavingly using the phrase 'you can/can't introduce...' -- it isn't quite like that, but that's the effect, so, I think, close enough for this discussion. ---- As an aside, a Clojure programmer might get a feel for what Haskell's state monad is like by considering the -> and ->> macros. Within the -> macro you start by defining your initial state then applying a sequence of operations to an updated state. You don't have to mention the state in your code again. The functions called in the -> and ->> macros have either their first or last argument 'receiving' the state and returns the updated state. This is like a simple form of the state monad. Haskell's state monad allows arbitrary computations and can be carried through (using the type system, not code) to sub-computations, not just a simple sequence of function applications. ---- That probably wasn't a lot of help, but... Cheers, Bob > 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. -- 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.
