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

[Gleb Peregud]

Forgot to include a link to my implementation:

https://github.com/gleber/erlfu


On Mon, Nov 19, 2012 at 11:32 AM, Gleb Peregud <gleber.p@REDACTED> wrote:

> 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/ca8d6635/attachment.htm>