Reia: Year 2

Yes, two years, the same as the number of heads on this turtle...

It's been two years since I committed the initial scanner to the Reia repository, which was the first commit of real code.  Last year I posted a large list of features which I had managed to crank out in the previous year.  But then I began to struggle with the codebase and implementation, and started to doubt some of the features I had been adding and suggested forking off the old implementation and starting over anew, as, alas, due to some poor design decisions Reia was unusably slow.

Rather than doing that, I decided to do a largely ground up rewrite, incorporating bits and pieces of the old code.  In the intervening time I had learned a lot about Erlang, like records are a necessary evil.  I had learned a lot more about how the Erlang compiler works and how people ordinarily write parse transforms, namely the extraordinary power of mapfold_subtrees.  After powering through the rewrite, the result was a much leaner, nimbler, and above all else comprehensible codebase with substantially better performance.

Unfortunately because of the rewrite I haven't managed to equal the same list of features the language could boast last year, but has picked up many new ones.  All your normal C-like bitwise operators now work.  C's ternary operator now works, and even supports the same wacky associativity as languages like C and Ruby (but unfortunately not the wacky left-associativity of PHP).  But even better, Reia now supports "magic rebinding" which allows you to use Reia's dicts with the same syntax as Ruby or Python, and even supports rebinding of a method's receiver using Ruby's method! syntax.

Recently I've added the basics of an immutable object system, and begun work on class-based polymorphism.  The goal is to put an OO-like face on a system similar to Erlang's parameterized modules.  Parameterized modules are an alternative way of storing structured data, created as an alternative to Erlang's records, one of the language's most shunned features.  However, it seems most people still steer clear of parameterized modules and find using them odd.  I hope Reia's immutable objects will provide the much sought after solution to this problem, by coupling state and function in the way Joe Armstrong so detests.

I would like for immutable objects to form the basis for almost everything in Reia.  The core types will be immutable objects.  Exceptions will be immutable objects.  External resources... you guessed it, immutable objects.

Does that mean processes, particularly ones like gen_servers, can also be immutable objects?  Maybe, but I'd much rather pursue making gen_server a first class part of the language.  Right now there's a considerable amount of boilerplate involved in creating a gen_server.  In the previous branch of Reia I managed to create a great proof of concept demonstrating a concurrent object system with "mutable" (yet behind the scenes still pure functional) instance variables using a syntax identical to Ruby's class definition syntax.  I still would like to add this back.

But in the meantime, I'm working on Reia again, immutable objects are on the way, and after that, the initial standard library and the first official release.