I like your looking forwards to the future Future, but I really want to
understand the conflict underneath Promises. I'm not trying to selectively
pick issues out, I'm trying to get a general sense for where the conflict
lies that kicked .chain out from complemeting the spec.
> The existing promises library users would be faced with a porting problem
> whose size is hard to estimate
Naive go here;
Promise.prototype.then= function(fn){
function recurse(val){
if(val.chain)
val.chain(recurse)
else
fn(val)
}
return this.chain(recurse)
}
> combinators such as .all do not use .chain, they use .then.
I've argued for nothing but giving everyone as many combinators as they want
in the spec. .then is a combinator of .chain, .all .some combinators of .then:
fine, great, shiny. You all get to join the spec, we won't try to change you
into doing something other than what you do now. Embrace the de riguere
standards!
These are not any reason the existing combinators cannot specify an
underpinning .chain that doesn't auto-unwrap. De jure has the chance to rule
that we can have it all, and the naive silly cheap code above moves towards
that promise, starts to show that the two are one & the same, & it's just
a question of what is pinned underneath.
I tend to believe there is for sure something real, and interesting under #3:
that there was a real issue in implementation that drove ES6 at the very last
hour away from .chain serving as the basis for .then. If you want something
other than cheap words an unreality, perhaps you'd color in some of those
details.
MF
On Tue, Feb 04, 2014 at 07:46:36PM -0800, Brendan Eich wrote:
> mfo...@eldergods.com wrote:
> >#3 is the only point I concede as being even possibly concrete
>
> Then you get a *plonk*, or at least a demeric, for ignoring the very
> concrete problem #2: combinators such as .all do not use .chain,
> they use .then. Also for ignoring #1 -- it doesn't matter that .then
> is compound, complex, multifarious -- it's a de-facto standard. And
> it is what combinators (#2) in the standard use, so you can't ignore
> the committee bloat or unioning cost.
>
> Imagine we simplified to do just .chain and .cast, and combinators
> called .chain. We'd be breaking compatibility with extant promises
> libraries, and de-jure future-banning .then/.resolve as an API
> alternative. The existing promises library users would be faced with
> a porting problem whose size is hard to estimate, since they are
> relying on assimilation and unwrapping happening behind the scenes.
>
> Promises *happened*. They are real. That's why I tweeted about #realism.
>
> Wanting something value-ish, featureless, monadic, is a good goal
> for a differently named abstraction built on value objects. Promises
> are not that abstraction. Do the work to show the win, under a new
> name (Future?). Until then this is selective arguing and cheap talk.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
