Summary: E / Erlang integration

Michael FIG fig@REDACTED
Fri Jun 9 23:10:09 CEST 2006


First of all, I want to say thanks to all those who have contributed to this
discusssion.  I think most of you have seen all the traffic, since some people
who appeared to be on both erlang-questions and e-lang have forwarded messages
from those who don't have posting access.

So, I'd like to resummarize the reasons I have for desiring an
E-compatible model within Erlang.  Erlang is already a melting pot for many
different kinds of messaging models, whether it is its native async messages
(that can be distributed to C or Java), other styles that are layered on
top of it (gen_server implements RPCs, gen_fsm implements event-driven state
machines), communication via CORBA, or drivers for passing custom-structured

Where I see E integration fitting is that each of Erlang's existing models
makes no special consideration for untrusted clients, untrusted servers, or
untrusted networks.  I don't think that's something that can be securely
grafted onto the existing Erlang messaging system, but I believe that E
has a proven model that doesn't burden the programmer.

To answer more about MarkM's comments, I'm talking about Erlang-E (E semantics
embedded in Erlang) rather than E-on-Erlang (an implementation of the E
language using Erlang as a VM).  I retract my original suggestion of
developing special syntax for E message sending (the !< part), since that
can easily be accomplished by a library function
"Promise = e:send(CryptoCap, Message)".  However, the when/catch construct
of E would be clunky to use without some syntactic sugar.

With sugar:

    promise_case e:send(RaceTrack, getPolePositionCar) of
        FarPolePositionCar ->
            io:format("My car is in pole position~n");
        after 3000 ->
            io:format("Timed out~n")
        catch E ->

without sugar:

    e:pcase(e:send(RaceTrack, getPolePositionCar),
            fun (SomeFreshName) ->
                 case SomeFreshName of
                    FarPolePositionCar ->
                        io:format("My car is in pole position~n"),
                    _ ->
            3000, fun () -> io:format("Timed out~n"),
            fun (E) -> ok end).

I'd like to get this or equivalent syntax solidified to make
the code I write somewhat more understandable, and to abstract the protocol
between the initiater of the promise_case and the process that actually
receives the results of the promise and dispatches to the promise_case arms.

So, I would like to proceed with implementing a library for E-style messages
based on the recommendations given by MarkM (quoted below so that people in
both communities may review it).

To meet my goals, this library would initially be a thin veneer over Erlang's
messaging, deliberately ignoring the issue of untrusted networks.  I also
want to document a safe subset of Erlang that uses the library for any
communication, and cannot block the host node or otherwise compromise the
security of other processes running on the node.  It would be important to
me to somehow annotate an Erlang module so that the compiler could enforce
that nothing outside that safe subset is used.

Mark S. Miller wrote:
> On practicality, perhaps I am underestimating how lightweight Erlang processes
> are. If they are lightweight enough, then this approach would work. To whit:
> When Erlang process X wishes to make a request and receive a response from
> process Y, X would make a new use-once process X2 which knows X's pid. X would
> then include X2's pid in the message to Y. When Y responds to X2, X2 would
> then wrap Y's response with a tag and send this response to X.
> Either these tags can themselves be unforgeable, or X's clients would also
> need to go through a tagging intermediate process so that a client couldn't
> send a message that X would mistake for Y's tagged response. I think it works
> for X2 to tag the message with X2's (presumed unforgeable) pid, since anyone
> who has that pid can respond on behalf of Y anyway.
> With enough care, X could reuse X2 for successive requests to Y. But if X
> wants to make requests of Z, it would need a separate X3 for that purpose.
> Otherwise, it enables Y to issues Z's response, and vice versa.
> The above scheme would meet the hard requirements. But how practical would it be?

I'm not too concerned about practicality initially: messaging to and from "safe"
Erlang processes layered on top of the standard Erlang messaging primitives
would probably still be cheaper than having cryptographically secure communication
(but I may be wrong).  On demand, and with enough acceptance in the Erlang
community, we could figure out how to optimize the e:send and e:pcase functions,
(probably making them builtins) as well as the corresponding E-style server

But that's a harder job than I'm prepared to commit to up front.  "Make it work,
then make it fast." ;)

> However, let's remember the original question. It seems both models can be 
> implemented in both languages. Erlang supports selective receive more 
> naturally. E supports non-blocking event-loops more naturally. Above, we 
> implemented selective receive in E, effectively simulating Erlang's selective 
> receive. If this is indeed the best solution to the problem, and it might be, 
> then we have a clear case where Erlang made the programmer's life simpler but 
> E made it more complex. Is there a better solution that's more natural for 
> non-blocking event loops? I don't know.

I would like to be able to use Erlang's system for performance reasons, and
choose the E model in circumstances in which I know a part of the system
is untrusted.  I also want to know that when I use the E model exclusively,
whether it be in Erlang or E proper, I have code that is easy to reason
about when it comes to privilege.  It would be interesting to see if E had
something to gain by providing support for Erlang's model, or if there is
some fused model we can arrive at.

If we get something that turns out to be useful, maybe somebody can talk to
the Mozart/Oz folks. :)


Michael FIG <fig@REDACTED>

More information about the erlang-questions mailing list