Re: Futures

On Mon, Apr 22, 2013 at 10:15 AM, Mark S. Miller <erights@google.com> wrote:

> On Mon, Apr 22, 2013 at 5:37 AM, David Bruant <bruant.d@gmail.com> wrote:
>
>>  Le 22/04/2013 14:26, Kevin Smith a écrit :
>>
>>
>>>  Thenable futures are uglier than branded futures, but also the only
>>> way to remain compatible with the various libraries that are out there
>>> today, which is something many people value.
>>>
>>>
>>  What about using a symbol for the `then` protocol?  Libraries can be
>> upgraded to use the symbol as an alias for `then`.  It set up a dependency
>> on ES6, of course...
>>
>> And it doesn't address the compatibility problem people want to address.
>> I personally wonder whether the compatibility with existing libraries is
>> so important. It should be pretty easy to wrap a native future into a
>> library future (aren't native futures already Promise/A+ compatible?) and
>> vice versa. Why isn't it enough to help with compatibility with libraries?
>>
>> Eventually, what will be the point of a promise library if there is
>> native support?
>>
>
> This is the great irony. Even if standard platform-provided ES promises
> win in the end, there will be a long transition period where there are
> several co-existing libraries. In order for standard platform-provided ES
> promises to win, it has to thrive in the environment of that co-existence.
> If it ever wins definitively, so that there are no remaining libraries of
> concern, it will no longer need the assimilation mechanisms that enabled
> that co-existence; but by then it will be too late to shed it. I would like
> a realistic way out of this dilemma. But after a tremendous number of
> messages on the promises/A+ site about exactly this issue (please read or
> at least skim), I don't think any of the alternatives are realistic. At <
> https://github.com/promises-aplus/promises-spec/issues/94#issuecomment-16244517>
> I write:
>
>
> The original E promise API which inspired all these others has no
>> assimilation. When I first heard about assimilation, I thought it was a
>> terrible idea, for many of the same reasons that underlie many of the above
>> objections. However, as I saw the JS promise landscape evolve, I despaired
>> more over a worse problem:
>>
>> Several similar but different elephants in the room: jQuery promises,
>> WinJS promises, Q promises, and DOMFutures. All of these but DOMFutures
>> have enough installed base that they're not going away. And re DOMFutures,
>> never underestimate the ability of the w3c to be an elephant even for
>> premature "standards". Much code will have to be written in an environment
>> inhabited by multiple such promise systems simultaneously. If none of these
>> recognize each other's promises as anything promise-like, then programmers
>> will face the burden of dealing with a "jQuery promise for a Q promise for
>> a WinJS promise for a DOMFuture for a number". Call it the
>> JQPFAQPFAWJPFADFFAN problem. I didn't see how we could get from that
>> situation to one with an agreed standard promise anything.
>>
>> Fortunately, the starting point for all of these elephants was so similar
>> that the Promises/A+ process was able to tease out and codify a
>> common-enough ground for all of these to agree on. This is messy real-world
>> standards work; as much politics and sociology as technology and math.
>> Given the constraints imposed by legacy, we should all be overjoyed that
>> the Promises/A+ community has been able to extract something as beautiful
>> as they did. But even if they all agreed on exactly the same spec, so long
>> as jQuery promises only recognize jQuery promises as promises, and likewise
>> for the others, we would still have the JQPFAQPFAWJPFADFFAN problem.
>>
>> Had ES6 with its unique symbols happened long before any of these promise
>> libraries, we could have used a unique "@then" symbol for assimilation and
>> so avoided the accidental collision @killdream worries about above.
>> Likewise, if all of these had stuck with the E (or original Q) name "when"
>> rather than renaming it "then", we would have less accidental collision,
>> and would be less irritating to category theorists. (FWIW, I think "when"
>> was a much better term than "then" for this anyway. I am still unclear on
>> the history of how this got renamed.) Alas, it didn't turn out that way.
>>
>

I may be partly responsible for this -- I think I helped convince Kris
Kowal, who championed the Promises/C proposal (not sure if there was ever a
Promises/B) which only used `when` that the `when` function could not be
made interoperable between libraries because it had to rely solely on
branding checks. This was back before Symbols were even a thing and
__proto__ was considered for standardization. The presence of either would
have cut my argument at the knees.


Given multiple promise systems that each recognize only their own promises
>> as promises, but which mostly agree on the meaning of "then", assimilation
>> turns out to be a surprisingly pleasant way for these to co-exist. Given
>> the actual situation we have to start from, having this assimilation be
>> based on duck typing on the presence of a function named "then" is
>> unfortunate, but there was no other practical choice.
>
>

Not at the time, no. When Symbols (née Names) were proposed I'd suggested
on this very list that they could be employed to solve exactly this
problem. At the time I guess this wasn't a problem people cared much about,
but this was before jQuery, WinJS and DOMFuture promises -- back when we
could have adapted to something more future-friendly -- a registry of keys
for branding, perhaps? I think I'd suggested that the module system could
serve as an ontology for these kinds of well-known symbols, and that we
could shim this functionality today. I'm sure all the really smart folks
grinding on this problem today would have had even better ideas. I'm glad
everyone's come around, but alas, too late to fix this :-/