[erlang-questions] Ideas for a new Erlang

[Vlad Dumitrescu]

Hi,

On Wed, Jun 25, 2008 at 5:49 PM, Christian S <chsu79@REDACTED> wrote:

> loop(Status) ->
>  receive
>    worker: {available, Worker} ->
>      addWorker(Status, Worker);
>    true: {job, Job} ->
>      dispatch(Status, Job)
>  end.
>

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

Regarding (a), this can be achieved without any syntax change (but not
without a price) and with a convention that is already in use. A kind of
"poor man's channels". Channels are identified by an Erlang term (a
constant) and can be created dynamically. The default one has an empty id. A
channel can be a separate mailbox or a data structure superimposed the
mailbox to allow traversing only selected messages. Messages are tuples
where the first element is the channel id. Any message not matching that is
in the default channel. The price is that receiving messages is somewhat
slower, since they must be sorted into the right channel. If no channels are
defined, this price is minimal and everything works as usual. Also, the
receive statements' patterns must explicitly contain the channel tag as a
constant or a bound variable.

The above may also be utterly flawed, but it doesn't feel so right now, to
me :-)

Regarding (b), I can't see how Erlang code can be made simpler. IMHO, in
other languages/environments, the use of channels is a way to structure the
code around the fact that there aren't any processes. The channels can be
asynchronous and Erlang-like coding can be used. But we already have
processes, and I fail to see how a channel would be distinguished from a
process like the ones we have now. Am I missing anything?

best regards,
Vlad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20080625/5b6b4292/attachment.htm>