I *really* don't want to wade deep into these waters, but I'll respond a bit here to correct errors:
On Nov 11, 2012, at 9:02 PM, Leo Meyerovich <[email protected]> wrote: > I've been lurking on this thread and am somewhat confused. Is the motivation > for promises a needed expressive primitive, updating the standard library to > have asynchronous calls and structure them via promises, sugar, or something > else? I assume it's not to proscribe one particular style of coordination > over another, which would have little empirical validation. Putting things into a language or standard library in no way "proscribes" alternatives; it does however anoint one variant as "idiomatic". To the extent a built-in does that, it should be following practice. Now, perhaps you haven't been watching the mis-designs in DOM or the ubiquitous promise/future/deferred-like libraries that are now part of every major JS toolkit on the client side (still our major user). Or perhaps you think that doesn't hold a lot of water as the language can go its own way (a view I'm *obviously* sympathetic to). But either way, I think Promises have value in that they: * were the basis for the underlying API we used to describe what happened when functions were de-sugared in the "await" proposal. They can do something similar for generators and, as someone who dislikes magic in general, I think we should do that work. * the weight of library authors sending down their own versions of this stuff is MASSIVE and *should* inform what we do. Any other bias needs massive justification. So yes, we have tons of validation on this. Just look around. Regards > -- If it's for asynchronous standard API, why shouldn't coordination be a > user-level framework decision? E.g., have one callback for each async API (or > two, succeed and fail), and leave the rest up to the coordination framework > of the day? Simple API structure, like one of these patterns, will help > framework writers make generic wrappers, but introducing more seems > excessive. The main use case for APIs would be (AFAICT) to allow frameworks > to introspect on whether an API call is async. Promises would enable > inspecting the return value, but this seems awkward and maybe even late. > > -- If the motivation is for language-level issues, I'm curious as to how this > relates to topics like compiler optimization, multiprocessing, cross-frame > communication, etc. Furthermore, are there any semantic concerns coming up > (e.g., E style vats), or is the intent here purely sugar? (I assume blocking > on a Liskov-style future will not be allowed). > > -- For sugar, a lightweight lambda and, if still desired, macros, seem to > eliminate much of the need of a primitive. > > Hopefully my confusion as to the motivation and design space here is clear :) > > Regards, > > - Leo > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss -- Alex Russell [email protected] [email protected] [email protected] BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
