Re: Question about E's history.

>
> It's interesting to note the many design dimensions of promises/futures
> that have been explored over the years, including:
> - whether "touching" or "claiming" a future/promise is blocking or
> non-blocking
> - whether "touching" or "claiming" a future/promise is implicit (by
> performing an operation that needs its value) or explicit (e.g. future.get()
> in Java, promise claiming in Argus)
> - whether the type Future<T> is distinct from the type T, in statically
> typed languages
> - whether futures/promises are created implicitly as the return value of a
> message send or explicitly as in the Multilisp form "(future expr)"
> - whether or not "pipelining" is supported
> - whether or not futures/promises support proper exception propagation
>
> Which only goes to say that "promise" and "future" are very overloaded
> terms :-)
>

Certainly true. I always strongly tie it to the blocking issue: to me
"futures" are blocking, "promises" are non-blocking. To my mind, that
distinction is the most crucial, because it is a prerequisite for pipelining
support. I realize that the literature uses the terms inconsistently, but I
don't know of a more convenient terminology to use to distinguish those
cases.

_______________________________________________
e-lang mailing list
[email protected]
http://www.eros-os.org/mailman/listinfo/e-lang