Lambda the Ultimate

NT

From Why Reia?

Reia brings both the ease of use of scripting languages and the immense capabilities of Erlang to build distributed, fault-tolerant systems.

It sounds as if the actual language design has given up on fault tolerance, in view of the comment James quoted...

I don't know enough about Reia, but there's a response elsewhere: Single Assignment Myths. I gather that the claim is that Reia remains true to immutable state, and what it really is doing is a mechanism that spins a new binding by allowing you the convenience to reuse names. An analogy would be in the ML REPL, where we might have something like:

> val x = 1;
val x : int = 1
> fun first () = x;
val first : unit -> int = _fn

> val x = 2;
val x : int = 2
> fun second () = x;
val second : unit -> int = _fn

> first();
val it : int = 1
> second();
val it : int = 2

Of course, ML only allows this convenience in the top level, but it probably is an instructive analogy to the way that I gather Reia works.

Now, one can argue whether name reuse makes reasoning more confusing. But I don't think the above is a case of mutable state.

Thanks for clarifying. That makes total sense.

If the apparent mutation is just a "let" rather than the mutation of a reference cell then it's not a source of shared mutable state.

In short, this is a syntactic nicety for SA that allows the user to write

a = foo
a = bar(a)
a = baz(a)

Instead of
a1 = foo
a2 = bar(a1)
a3 = baz(a2)

I'm pleased to see that my comment attracted a bite, and delighted to see that the biter is Tony Arcieri, who is quite fair when he says It’s clearly not a comment that the author put a lot of thought into, since his counter, that fault tolerance comes from the high-level infrastructural properties and not the low-level semantical properties, occurred to me shortly after I closed the browser after posting my remark. While I do think that part of that infrastructure is a code design approach that leverages the low-level property of immutability, modulo this concern his further points WRT myth #2 are fair.

I suspect, though, that his points WRT myth #5 are not fair. It is certainly no defence against the charge of immutability to say that the language supports an operational semantics expressed in an intermediate representation that respects single assignment. Mutation can always be modelled by rebinding, that is the whole point of the SSA construction algorithm.

This is still not a comment into which I have put a lot of thought, since I have not carefully evaluated Reia's violation of single assignment to see if it is innocent, like the example from ML that Chris brings attention to, or not.

Mutation can always be modelled by rebinding, that is the whole point of the SSA construction algorithm.

As far as I know, that's not necessarily true with concurrency.

And while it's technically true with sequential programs, the transformation is not a local one when closures capture mutable variables or you've got shared mutable objects/records.

It appears that Reia is just doing nested localized "lets" in a syntactically flat way so there's no side effecting going on at all.

I think Charles was referring to mutation of locals only. All the SSA stuff I've seen doesn't deal with main memory, only with locals.

James guessed my meaning correctly. The issue is one of what the nature of SSA construction for Reia is, and what what possible issues rebinding raises for reasoning about concurrency. I'm pleased that James has looked over it and is happy, but I shall take a look as well.