printsAll :: FilePath -> IO String
printsAll f = do
h
will print the entire contents of a file, but

printsNothing :: FilePath -> IO String
printsNothing f = do
h
doesn’t print anything. This is entirely because of an interaction between Haskell’s non-strict semantics and evaluation order. I think if you force evaluation of s using deepSeq before closing the file, it does print the contents.

I understand the atomic consistency of references. The value isn’t for the threads doing the fine-grained reads and writes, it’s for the concurrent coarser-grained transactions manipulating those same refs, which are able to see a snapshot of the world for their duration strictly because the fine-grained activity also participates in the transaction system.

Obviously, unconditional atomic overwrites of shared refs have limited utility in a concurrent program, but the above guarantee matters, especially when additional concurrent use is added later, as it so often is.

But I don’t see the point you’re making about the utility of transactionally protecting a single read or single write to a ref as compared to not using transactions at all. The JVM already guarantees atomicity of reads and writes to references.

I could write the following in Java

class Ref[T] {
private T x;
public Ref(T x) {this.x = x;}
def get {return x;}
def set(T newX){x = newX;}
}

If multiple threads bang against one instance of this I should get the same guarantee as multiple threads doing ultra-fine grained transactions in Clojure. The pointer would never be corrupted, but a thread that does two quick reads in succession or a write and then an immediate read would have no promise of seeing the same value twice.

That’s not to bash Clojure or STM in general. It’s just the nature of transactions: they only give you as much consistency as you allow them to.

I found this thread only recently, so sorry to chime in late.

>The fact that it’s “transactional” is invisible to the client code and in fact rather useless as each transaction protects only a single mutable reference.

The ‘transactionality’ of these atomic functions is not useless at all. If some other thread were using the same ref x, it could make transactional read-modify-write decisions without being corrupted by the actions of these functions. Also, while it’s not idiomatic to write such fine grained transactions, a set of calls to these functions could be placed in an enclosing transaction and would join it, thus allowing the composition of more coarse-grained transactions.

Of course you can define such a thing.

static funcPtr theFirstFunction;
static funcPtr theSecondFunction;

int theComposedFunction(int x){
return theFirstFunction(theSecondFunction(x))
}

funcPtr compose (funcPtr f, funcPtr g) {
theFirstFunction = f
theSecondFunction = g
return *theComposedFunction
}

(Or something like that. I always forget the details of C)

What do you mean “re-entrant”?