Re: A Challenge Problem for Promise Designers

On 26 April 2013 14:29, David Bruant <bruant.d@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
>> space:
>>
>> 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
>> time).
>>
>> 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).

/Andreas

Received on Friday, 26 April 2013 13:38:55 UTC