[erlang-questions] Ideas for a new Erlang

[Sven-Olof Nystr|m]

Ulf Wiger writes:
 > 2008/6/25 Vlad Dumitrescu <vladdu55@REDACTED>:
 > >
 > > I'm not sure I get the reason why channels would be useful. I see two
 > > possibilities:
 > > a) for performance, when each channel has a different mailbox
 > > b) to simplify the code/architecture
 > 
 > I don't think channels would simplify the code, but they might make
 > it easier to reason about it. The thing that selective receive brings to
 > the table is scoped message reception. The Erlang approach of
 > pattern-matching on a single message queue is extremely flexible,
 > but it's difficult to "prove" the code correct. For example, it is quite
 > possible for a piece of code to consume someone else's 'DOWN'
 > message, by ignoring the Ref part. If channels followed the same
 > scoping rules as variables (and channels aren't just syntactic sugar
 > on top of a single message queue), a function could not steal someone
 > else's messages.

Yes. This is actually one of the reasons I am interested in
alternatives to selective receive. Any kind of formal reasoning about
process communication would benefit from the channel concept. I didn't
mention it in the paper since I was concerned that a discussion would
be too complicated. Also, I thought that the reasons I gave were
sufficient.

As you say, the use of selective receive makes it harder to determine
the set of messages that should (and shouldn't) arrive in the mailbox
of a particular process.

 > Not that these kinds of bugs are commonplace in Erlang. It's quite
 > easy to avoid them using simple conventions. But there is, after all,
 > a difference between "easy to avoid" and "impossible", which can
 > sometimes be significant.

No, it seems that the Erlang developers have learned how to live with
selective receive.

 > Haskell has channels, and so does .NET (mailbox objects). There is
 > therefore an opportunity to compare programs and try to determine
 > whether programming with channels makes for more or less
 > readable code than erlang's selective receive.

OK.


Sven-Olof