[e-lang] [Fwd: Re: Proposal: E / Erlang integration]

David Hopwood <>
Fri Jun 9 06:35:37 CEST 2006

David Hopwood wrote:
> It may be instructive to show how this example would be handled in E.
> The executive summary is that E can implement it with the "non-blocking
> restriction" just as straightforwardly as the blocking code, even though
> E does not support selective receive:
> # Like the Erlang example, we don't handle errors.
> # The hardware, which can be controlled asynchronously.
> def lim {
>     to startTone(tone :String) { ... }
>     to stopTone() { ... }
>     to startRinging() { ... }
> }
> def makePOTS() {
                ^ :any
>     return def pots {
>         # Declare the states, to avoid forward references...
>         def waiting, idle, getting_first_digit, ringing_B_side, calling_B,
>             ringing_A_side, speech
>         # The peer we are connecting to.
>         var B
>         # The number being dialed.
>         var number :String := ""
>         # This is just a way to make a process that has different behaviours
>         # over time look like a single object.
>         var state := idle
>         match [verb, args] { E.call(state, verb, args) }
>         # Now define the states...
>         # waiting is a dummy state used while we are waiting for the hardware.
>         # (In a real example there would have to be a way of getting out of this
>         # state if the hardware fails, but the Erlang code doesn't deal with that
>         # either.)
>         bind waiting {}

Actually, it can't quite be done this way because messages received in the waiting
state would cause a crash (and it is not correct to ignore them).

If the intent is to delay any messages until we get out of the waiting state, then
the following would work (but would be inefficient, as discussed in the earlier
thread at <http://www.erlang.org/ml-archive/erlang-questions/200507/msg00301.html>):

          bind waiting {
              match [verb, args] { E.send(pots, verb, args) }

Hmm, maybe selective receive would be beneficial here. I don't think it is
incompatible with the rest of E's concurrency model, and I think it can be
implemented purely in E as a reusable abstraction (using an actors-style
'receptionist' that buffers messages until they can be matched -- see
section 3.6 of <http://www.cypherpunks.to/erights/history/actors/AIM-781.pdf>).

OTOH, I'm not entirely convinced that buffering messages until we leave the
waiting state (as the Erlang code implicitly does) is exactly the right thing.
For example, if we get an 'offhook' message, or if the hardware fails, then the
message buffer should be flushed. I don't think there's any way to do that in
Erlang (there is with the receptionist approach).

David Hopwood <>

More information about the erlang-questions mailing list