[erlang-questions] Futures/promises and ability to "call" abstract modules

[Gleb Peregud]

Hello

Last evening I was trying to implement futures/promise mechanism in Erlang
(mostly for fun, since I am still unsure if it is useful). I got inspired
with the presentation [1], which mentioned using futures as a foundation of
building services, where things like timeouts, tracing, authentication,
etc. is built by composing futures (see slide 41).

Do you think that such composition of futures could be useful as a tool to
improve code reuse of communication patterns in Erlang (as described in the
presentation)?

I've implemented futures using processes and message passing and stumbled
upon two issues:
1) garbage collection of futures
2) slightly too much code when using them

Example of the first problem is here:

1> F = future:new(fun() -> timer:sleep(10000), 10 end).
{future,<0.36.0>,#Ref<0.0.0.1736>,undefined}
2> F:get(). %% it hangs for 10 seconds
10

Since future F is represented as a process <0.36.0> it will stay running
forever till it's timed out (which is not a good solution, since someone
may still have a reference to this future) or F:done() manually called.

My idea is to insert into 'future' tuple a NIF-generated resource, which
will have a destructor attached (called upon garbage collection of the
resource) which will call F:done(). Will it work?

The second issue is illustrated here:

7> F = future:new().
{future,<0.47.0>,#Ref<0.0.0.27235>,undefined}
8> spawn(fun() -> timer:sleep(10000), F:set(42) end).
<0.49.0>
9> F:get().
42

In ideal world it should be enough to just write "F" (without :get()) to
fetch future's value, but it seems too far fetched for Erlang. Slightly
better solution would be to allow calling future with "F()".

This can be done by extending concept of "abstract modules" with "default
call". Currently abstract modules allow the following:

{future, Pid, Ref, undefined}:get() which is translated to
future:get({future, Pid, Ref, undefined})

With a simple change in beam_emu.c in call_fun function (which would
replace obsolete fun tuples) we can allow for the following:

{future, Pid, Ref, undefined}() which COULD be translated to
future:call({future, Pid, Ref, undefined})

hence allowing to use just "F()" to read a value of the future. This will
also extend "metaprogramming" capabilities of Erlang for some other quirky
use, which may or may not be a Good Thing(tm).

Thoughts?

Cheers,
Gleb Peregud

1: http://monkey.org/~marius/talks/twittersystems/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121119/57a41a52/attachment.htm>