Reia: Python/Ruby style language on top of Erlang

I thought this was an interesting effort:

Reia (pronounced RAY-uh) is a Python/Ruby-like scripting language for the Erlang virtual machine (BEAM). Reia aims to expose all the features and functionality of Erlang in a language more familiar to programmers of scripting languages, while improving string handling, regular expressions, linking with external libraries, and other tasks which are generally considered outside the scope of Erlang. Reia is distributed under the MIT License.

If it were just the syntax, that would be sort of interesting, but maybe nothing too special. However, they're also attempting to create an object system on top of Erlang, which if I'm not mistaken uses an Erlang process per object.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Such Nice Syntax

This language has synthesized many good things from Python & Ruby (which have synthesized them from elsewhere, of course). Indentation sensitivity, ed/sed/perl regex syntax, Ruby blocks. Wow.



Mutation and message passing

From the FAQ.

Multiple assignment? Gag me with a spoon!

Reia supports the ability to rebind new values to the same varible. This is, to date, the most controversial feature of Reia. While Erlang supports single assignment and prevents variables from being mutated through side effects, Reia makes this possible by abstracting what variables are actually bound to from how they appear to be bound from the programmer's perspective.

This means Reia allows far more side effects than languages like Erlang, and side effects have been long regarded by both functional and concurrent programmers as a nasty source of bugs which should be avoided.

However, most programmers are used to using languages which allow more side effects than Erlang, and furthermore enjoy using operations with side effects to accomplish tasks quickly. While Reia may be more error-prone than Erlang, it will also be more accessible to the average programmer who is not familiar with single-assignment languages and would require a conceptual leap in order to understand them.

Isn't Reia supposed to be a concurrent language? Where's all the concurrency primitives?

Right now the focus is to get Reia on par with sequential Erlang. The concurrency primitives will come with time, but for now the focus is getting sequential programming rock solid first.

Why Reia?

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

Single Assignment and Immutability

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.

Good point

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)

Side effects and fault tolerance

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.

No side effects

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

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.

The inscrutably non-local SSA construction algorithm

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.