The Paradox of Partial Parametricity

Russell Leggett russell.leggett at gmail.com
Sun May 26 07:30:43 PDT 2013


On Sat, May 25, 2013 at 6:00 PM, Brendan Eich <brendan at mozilla.com> wrote:

> Tab Atkins Jr. wrote:
>
>> AP2 from Mark's slides:
>>> >
>>> >  AP2 (Based on Tab’s latest)
>>> >  • Q.fulfill // lifting
>>> >  • Q() // autolifting, resolve
>>> >  • p.then // deep flattening
>>> >  • p.flatMap // “chain”
>>>
>>
>> Apologies for being a broken record, but just to make sure the detail
>> isn't lost in the noise...
>>
>> AP2 is*almost*  right.  If .then() only flattens on the read side,
>> it's perfect.
>>
>
> With you all the way on this one.
>
> Who proposes flattening the return value ("write side", right)?



Just one more from the peanut gallery. I'm a big fan of the Q library. I
use it in production code. I like the auto-unwrapping and feel like it
works in a way that I expect. I like E and greatly respect Mark's work and
opinion as well. I can't really think of any situations where I would need
nested promises. Still, in this debate I find myself coming around to Tab's
proposal, including his details about flattening on the read side. I
strongly come down on the path of using thens and recursive unwrapping as
the happy path that everyone should really use unless they know what
they're doing. Still, the additional method does not come at a high cost in
my opinion. If there is going to be a standard "hacky workaround", then the
additional method seems pretty straightforward and elegant.

On the other hand, if *nobody* is going to actually need the method, then I
guess it may very well be dead weight. I'm sorry if I have just missed it
trying to keep up to date, but what are the compelling use cases. I mostly
understand the monad thing, I can recognize them when I see them - I've
used haskell. Is the only reason so that a monadic style can be used, with
promises included? Perhaps that's enough, but I guess I'd really like to
hear something more direct. Also, I'd like to know how many people are
really using monadic JavaScript in production or if its mostly just a
hypothetical scenario.

Finally, if we wish to add the method and we worry about the burden on
developers who have no interest in monads, perhaps a method name that
really comes from *their* perspective, or one that feels more *experts
only* would seem less burdening. Something like "resolveOnce" or
"forceInvokeNext" or "resolveNonGreedy" or even "monadicThen". Some of
those are probably more acceptable than others, but I think that "chain"
will too likely seem useful to people who won't want to use it. JavaScript
developers, I think have expectations about what chain means. For most
people, they with just think of wrapping something for method chaining.

- Russ


>
>
> /be
>
> ______________________________**_________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130526/a1df49db/attachment.html>


More information about the es-discuss mailing list