[erlang-questions] Ideas for a new Erlang

[Sven-Olof Nystr|m]

Thomas Lindgren writes:

 > Selective receive and channels: There seem to be two arguments
 > against selective receive. 

A third argument: Erlang processes use their mailboxes for two
purposes: 

 1) To receive requests for whatever service the process provides.

 2) For internal communication. Whenever a process needs to send a
    request to another process or simply ask a question, the response
    will arrive in the mailbox and needs to be extracted using
    selective receive.

I think it is better to use separate channels for the second purpose.

 > First, that it is hard to understand. That's not my experience.

Most examples that take advantage of selective receive's ability to
scan the mailbox follows a simple pattern. I agree that code following
this pattern is easy to understand.

 > Also, as I recall, Concurrent ML and its channels yielded some
 > horribly convoluted examples when trying to write POTS. 

Others have also mentioned the difficulties in writing POTS in CML. It
seems to me that a solution using CML's buffered channels would be
very similar to an Erlang solution. It would be interesting to learn
more about the CML solutions. What did they look like, and why were
they terribly convoluted?

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

A better implementation could certainly improve performance of
applications that spend a lot of time scanning the mailbox, but I
suspect that it would be better to rewrite such applications.

 > (Regarding channels: changing how receive works seems so
 > fundamental that the path of least resistance might be to just
 > switch to Concurrent ML.)

Or to leave things the way they are.

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

'm' is another module. 

At the time of writing, I thought the linked_module proposal was the
weakest of my proposals. I still decided to leave it in, as I thought
that the issue was important and deserved to be addressed.

Richard O'Keefe mentioned that he had proposed something similar.

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

You are putting it better than I did.

 > (The next erlang might first of all have a nice, preinstalled way
 > of revising the language :-)

I'm not sure what a mechanism for revising the language would look
like.

Lisp's macros offer a way to experiment with the language without
modifying the implementation. I think this helps the development of
the language in the long run.

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

I'll try to come up with something :-)



Sven-Olof