A Challenge Problem for Promise Designers
rossberg at google.com
Fri Apr 26 06:38:06 PDT 2013
On 26 April 2013 14:29, David Bruant <bruant.d at gmail.com> wrote:
> Le 26/04/2013 13:24, Andreas Rossberg a écrit :
>> I'm not sure if your description of E is accurate -- I'd find that
>> surprising. It _is_ a perfectly sensible design to have transparent
>> futures that you can just use in place of the value they eventually
>> get resolved to (let's call that value their 'content'). In fact, that
>> is how futures/promises where originally proposed (back in the 70s)
>> and implemented (e.g. in MultiLisp in 85, Oz in 95, and others later).
>> However, there are really only two consistent points in the design
>> 1. Either, futures are objects in their own right, with methods and
>> everything. Then they should be fully compositional, and never be
>> equated with their content, even after resolved (because that would
>> change the meaning of a reference at locally unpredictable points in
>> 2. Or, futures are entirely transparent, i.e. can be used everywhere
>> as a placeholder for their content. In particular, that means that
>> 'f.then' always denotes the 'then' method of the content, not of the
>> future itself (even when the content value is not yet available).
>> Unfortunately, option (2) requires that accessing a future that is not
>> yet resolved has to (implicitly) block until it is (which is what
>> happens in MultiLisp and friends).
> I'm adventuring myself in places where I don't have experience, but I dont
> think blocking is what *has to* happen. Programming languages I know all
> have a local-by-default semantics, that is all values being played with are
> expected to be local by default (which sort of makes sense for in
> single-machine environments).
> A programming language could take the opposite direction and consider all
> values as remote-by-default. If values are remote, with event-loop
> semantics, you never really block.
Note that futures/promises, by themselves, do not have anything to do
with distribution. But yes, you could implicitly wrap _every_
operation into a separate computation returning a future. That would
be pretty close to what lazy languages do (a lazy thunk is basically a
form of future). Unfortunately, it is also known to interact horribly
with side effects, by making their order highly unpredictable (despite
the semantics still being deterministic).
More information about the es-discuss