[erlang-questions] Ideas for a new Erlang

[Thomas Lindgren]

--- On Tue, 6/24/08, Sven-Olof Nystr|m <svenolof@REDACTED> wrote:

> From: Sven-Olof Nystr|m <svenolof@REDACTED>
> Subject: [erlang-questions] Ideas for a new Erlang
> To: erlang-questions@REDACTED
> Date: Tuesday, June 24, 2008, 4:23 PM
> Hello everyone, 
> 
> I have written down some thoughts and ideas on the future
> development
> of Erlang.
> 
> Main topics:
> 
>  - some notes on implementation and backward compatibility
> 
>  - an alternative to Erlang's selective receive
> 
>  - a simple language mechanism to allow function in-lining
> across
>    module boundaries
> 
>  - a new mechanism for introducing local variables with a
> more cleanly
>    defined semantics
> 
>  - a mini-language to allow the efficent implementation of
> low-level
>    algorithms

A quick, possibly shallow, read of your proposals.

Selective receive and channels: There seem to be two arguments against selective receive. First, that it is hard to understand. That's not my experience. Also, as I recall, Concurrent ML and its channels yielded some horribly convoluted examples when trying to write POTS. Thus, such gains from channels seem quite unclear to me. Second, that selective receive can be inefficient. But is it _inherently_ inefficient, or just suffering from a lack of attention to some cases? Could better implementation techniques solve this? (Regarding channels: changing how receive works seems so fundamental that the path of least resistance might be to just switch to Concurrent ML.)

Linked modules: a difficult issue in practice. I have thought about how to do this in the context of optimization for quite some time, but one should note that hot code loading is a feature that trumps quite a lot of others in practice. Also, what do we really mean when we write "-linked_module(m)."? To what does 'm' refer, for example? (I'll happily agree that records are an abomination.)

Variable bindings: these currently leave something to be desired -- computing what variables are bound or used and when they stop living in a function is far too messy. But I'm not convinced that the idea of either exporting expression values or bindings is what we need.

A number of features of Erlang have been introduced pell-mell and then could never be retracted (records; three nearly-identical sorts of guard operators; two identical forms of guards, etc). A fresh version of Erlang would do well in pruning back a lot of these and just putting back the ones with a point. (The next erlang might first of all have a nice, preinstalled way of revising the language :-)

Finally, the discussion needs some compelling examples. Would we really get substantially better code over what we have today? Demonstrate.

Best,
Thomas

PS. As an aside, Dr Nystr|m, isn't it time to join the age of unicode? :-)