Yes they are, but I think "for loops" and "mutable lists" a'la Java's ArrayList and Vector and C#'s List<T> don't exist even in IO (I'm not a Haskell expert). That kind of thing has to be done with recursion. They exist in F# but are not idiomatic. However sometimes they're more intuitive (to me at least).

forM is a for each loop over anything iterable (Traversable in Haskell) that will execute a given monadic action on each element in the collection. A more traditional for loop is this over a range of integers or whatever else you feel like.

    forM (range 5) println

Mutable collections exist in various forms depending on what kind of mutability you want. For example, there's transactional mutability that gives you mutable data structures inside an STM but forbids IO. And there's IO mutability that removes all the bounds but restricts you to the IO Monad. TVars, MVars, and the various kinds of Refs are what you're looking for here.

If someone is asking for mutability for reasons of performance and clarity, giving them STM is like a kick in the teeth.

How is STM like a kick in the teeth? In performance? How? In clarity? How?

Can you give examples of STM being a kick in the teeth versus mutability.

I suspect he didn't keep the size of his stm atomically programs small. The docs and associated papers and book materials all make it very very clear that you want to keep stm transactions small and try to defer computation into thinks that are only evaluated when the transaction succeeds.

Compare the cost of optimally, expertly built STM-using code to, say, just assigning some byte values in a *char array. Instruction count? Cache locality? Allocations?!?

EDIT: Oh, and isn't STM typically just a wrapper over immutable stuff anyways? So he said "immutable copying is too slow for me", and you said "here, use this instead, it has all the copy overhead plus some additional overhead".. that's a kick in the teeth.

> Compare the cost of optimally, expertly built STM-using code to, say, just assigning some byte values in a *char array

This is comparing the wrong tasks. Apples and oranges.

STM is usable for this particular task, but will almost assuredly be far slower. If performing the exact same task in Haskell, you could use IO and mutable memory for comparison.

Where STM really shines, however, is in highly-concurrent environments. There's no great "C comparison" for hundreds of concurrent operations locklessly reading/writing to/from the same memory. STM makes this safe and performant without a change in semantics or additional mental overhead from the "non-concurrent" case.

I'd limit your case to "highly-concurrent environments where want lots of shared, mutable state". There's always cases for some shared or global thing that you're transacting with, but I think 99% of code in highly-concurrent environments should be written with message-passing and limited scope at any point in the program.

... Stm in ghc is definitely mutable. Before commit it has an oplog representation but it's most assuredly doing very imperative things like find grained locking and writes to the same reference :)

Ah, well that's super cool. Doesn't completely counteract what I was saying but that's interesting, thanks for the tid bit.