"in Clojure I rarely find myself reaching for something like the state monad, as I would in Haskell"

[Julian]

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. 

[Timothy Baldridge]

When I first wrote the core.async go macro I based it on the state monad. It seemed like a good idea; keep everything purely functional. However, over time I've realized that this actually introduces a lot of incidental complexity. And let me explain that thought. 

What are we concerned about when we use the state monad, we are shunning mutability. Where do the problems surface with mutability? Mostly around backtracking (getting old data or getting back to an old state), and concurrency. 

In the go macro transformation, I never need old state, and the transformer isn't concurrent. So what's the point? Recently I did an experiment that ripped out the state monad and replaced it with mutable lists and lots of atoms. The end result was code that was about 1/3rd the size of the original code, and much more readable. 

So more and more, I'm trying to see mutability through those eyes: I should reach for immutable data first, but if that makes the code less readable and harder to reason about, why am I using it?

Timothy

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
“One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.”
(Robert Firth)

[Bob Hutchison]

On May 16, 2014, at 8:49 PM, Julian <julian...@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. 

[Ben Wolfson]

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).

--

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@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+u...@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+u...@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]

[Ben Wolfson]

On Mon, May 19, 2014 at 7:48 AM, Bob Hutchison <hutch...@recursive.ca> wrote:

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).

You can use regular IO in an STM action with unsafeUItoSTM: <http://hackage.haskell.org/package/base-4.7.0.0/docs/GHC-Conc-Sync.html#v:unsafeIOToSTM>. IMO it's advantageous that you have to explicitly say that you want to do IO inside a transaction, given that (in general) you probably shouldn't be doing it.

[Bob Hutchison]

On May 19, 2014, at 1:44 PM, Ben Wolfson <wol...@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)

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)

[Bob Hutchison]

On May 19, 2014, at 1:50 PM, Ben Wolfson <wol...@gmail.com> wrote:

On Mon, May 19, 2014 at 7:48 AM, Bob Hutchison <hutch...@recursive.ca> wrote:

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).

You can use regular IO in an STM action with unsafeUItoSTM: <http://hackage.haskell.org/package/base-4.7.0.0/docs/GHC-Conc-Sync.html#v:unsafeIOToSTM>. IMO it's advantageous that you have to explicitly say that you want to do IO inside a transaction, given that (in general) you probably shouldn't be doing it.

You’re right. I didn’t want to bring that up though. It’s well named. I used the various unsafe* functions regularly while debugging, and even then only for writing to the console. I would be *very* *very* reluctant to use any of them in production, and certainly not intentionally design something that required their use. So, for the purposes of this discussion, I figured I’d just pretend they didn’t exist.

Cheers,

Bob

--
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]

[Ben Wolfson]

On Mon, May 19, 2014 at 11:28 AM, Bob Hutchison <hutch...@recursive.ca> wrote:

On May 19, 2014, at 1:44 PM, Ben Wolfson <wol...@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.

 

[Bob Hutchison]

On May 19, 2014, at 2:45 PM, Ben Wolfson <wol...@gmail.com> wrote:

On Mon, May 19, 2014 at 11:28 AM, Bob Hutchison <hutch...@recursive.ca> wrote:

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

Hmm. I’m going to have to take another look at that. Thanks!

[Phillip Lord]

Julian <julian...@gmail.com> writes:
> 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 find myself reaching for the state monad all the time; then I realise
that, still, no one has been able to explain what a monad is in a way
that I understand, so I stop.