Hello<br><br>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).<br>

<br>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)?<br><br>I've implemented futures using processes and message passing and stumbled upon two issues:<br>

1) garbage collection of futures<br>2) slightly too much code when using them<br><br>Example of the first problem is here:<br><pre><code>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</code></pre>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.<br>

<br>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?<br><br>The second issue is illustrated here:<br>

<pre><code>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</code></pre>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()".<br>

<br>This can be done by extending concept of "abstract modules" with "default call". Currently abstract modules allow the following:<br><br>{future, Pid, Ref, undefined}:get() which is translated to future:get({future, Pid, Ref, undefined})<br>

<br>With a simple change in beam_emu.c in call_fun function (which would replace obsolete fun tuples) we can allow for the following:<br><br>{future, Pid, Ref, undefined}() which COULD be translated to future:call({future, Pid, Ref, undefined})<br>

<br>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).<br>

<br>Thoughts?<br><br>Cheers,<br>Gleb Peregud<br><br>1: <a href="http://monkey.org/~marius/talks/twittersystems/">http://monkey.org/~marius/talks/twittersystems/</a> <br>