Proposal: E / Erlang integration

[Michael FIG]

Greetings to E and Erlang people, both.

[First, to qualify this message, I'm a novice in both the Erlang and E worlds, so please forgive me if I make some incorrect assumptions.  Many thanks if you take the time to correct me. :)  I think that both the e-lang and erlang-questions lists are subscriber-only, so I will try to summarize responses to the other list if that turns out to be true.]

I would like to introduce each of you to the other:

E (http://www.erights.org/) is an object-oriented, secure, distributed capability-based language with its main implementation in Java and a secondary implementation written in Common Lisp.

Erlang (http://www.erlang.org/) is a mature functional, process-oriented, distributed language with its own virtual machine.

I am writing because I think that E uses an excellent architecture for sending messages between mutually-untrusting components (based on _promises_, also known as _refs_ or _vows_), and because I like Erlang (it is fun to write applications using a dynamically-typed functional language).

Erlang fits all the present needs of my applications, but I recognize that in the future my distributed applications will probably need to communicate with untrusted components across untrusted networks.  I like E's architecture, but really don't want to have anything to do with Java-like syntaxes.

In my mind, the only things that would need to be changed in Erlang in order to support E's semantics  would be syntax to send E-style messages (that result in a promise), a construct to invoke code when promises are fulfilled, and a flag to indicate that a specific process is untrusted and may only interact with the rest of the system by receiving and sending E-style messages.

For E-style eventual sends, I propose:

    Promise = Target !< Message

something like:

    LocationPromise = MyCar !< {moveTo, 2, 3} % An asynchronous send which results in a promise

and for associating a promise with result callbacks:

    io:format("Associating LocationPromise with callbacks~n"),
    promise_case LocationPromise of % This is E's when/catch in more Erlang-friendly syntax
        {X, Y} when is_integer(X) and is_integer(Y) -> % The promise resolved to a tuple
            io:format("Now at location ~p,~p~n", [X, Y]);
        catch E -> % thrown exception or bad match
            io:format("Promise broken ~p~n", [E])
        after 3000 -> % timeout
            io:format("Promise took more than 3 seconds to resolve~n")
    end,
    io:format("Continuing execution~n")

which would print:

Associating LocationPromise with callbacks
Continuing execution
[... and sometime after LocationPromise is resolved into moveTo's return value]
Now at location 2,3

"promise_case" in this example does a deep scan of its argument, recognizes which are promises, and spawns a process that will wait on those promises and execute the associated callbacks when all have been resolved.


The server side of MyCar would be something like:

-behaviour(gen_server).
-export([handle_send/2]).

handle_send({moveto, X, Y}, State) ->
    {reply, {X, Y}, State};
handle_send(Msg, State) ->
    {throw, {unexpected_message, Msg}, State}.

Where the gen_server behaviour could be extended to recognize E-style sends and dispatch them to handle_send.  I expect that untrusted processes would be able to export their own handle_send implementations, so long as they only used E-style eventual sends and safe Erlang primitives in their bodies.

The advantage to the E community would be yet another implementation and popularization of E.  The advantage to the Erlang community would be a robust model for secure distribution and a mechanism for executing untrusted Erlang code which is far more effective than "sandboxing" techniques.  Initially, I only want to define the syntax and semantics and implement them in Erlang... adding cryptography and compatibility with the existing Elib is something that I would like to defer until later.

I am prepared to work on the implementation, but I do need to hear what people in each community think about this.  I would like to come up with something that both communities are happy with, so that we can work together.

Thanks,

-- 
Michael FIG <fig@REDACTED>