The Paradox of Partial Parametricity

Dean Landolt dean at
Tue May 28 10:57:29 PDT 2013

On Tue, May 28, 2013 at 12:24 PM, Russell Leggett <russell.leggett at
> wrote:

> On Tue, May 28, 2013 at 9:55 AM, Tab Atkins Jr. <jackalmage at>wrote:
>> On Mon, May 27, 2013 at 9:53 AM, Russell Leggett
>> <russell.leggett at> wrote:
>> > On Mon, May 27, 2013 at 11:04 AM, Tab Atkins Jr. <jackalmage at>
>> > wrote:
>> >> On Mon, May 27, 2013 at 7:29 AM, Russell Leggett
>> >> <russell.leggett at> wrote:
>> >> > I'm just going to go ahead and play stupid here. Why is it called
>> chain?
>> >> > I
>> >> > agree one more method doesn't break anyone's brain, but I think the
>> >> > confusion comes when it is not clear what a method is for and when
>> they
>> >> > should use it. Can anyone just try to write a really quick API doc
>> for
>> >> > chain
>> >> > so that someone without knowledge of monads could read it? It should
>> >> > hopefully be fairly obvious after reading the doc why the method is
>> >> > called
>> >> > chain.
>> >>
>> >> Yeah, it's pretty easy - the chain() method lets you "chain" one
>> >> promise into another - you start with a promise, take a function that
>> >> returns a promise, and return a promise from that.
>> >>
>> >> (Naming abstract operations is hard, but I think chain() is better
>> >> than bind().  This is probably why Haskell spells it ">>=". ^_^)
>> >
>> > Technically speaking, though, doesn't "then" also meet that definition
>> (plus
>> > additional functionality)? I agree that naming abstract operations is
>> hard,
>> > but this just screams to me of a method that would get improperly
>> > used/confused by developers. It would work like then in some cases, but
>> > break unexpectedly, etc. Brendan says no name mangling, and sure it
>> probably
>> > shouldn't be too bad, but I think it should be on the burden of chain to
>> > distinguish itself from then, and not the other way around. ES is
>> already
>> > filled with names like getOwnPropertyDescriptor. For the amount of use
>> it
>> > will get, I'm not sure it's worth a shorter, more cryptic name.
>> "then" works equally well for promises, but I don't think it works for
>> arbitrary containers - I think I'd understand "array.chain(cb)" better
>> than "array.then(cb)".
> I wan't suggesting using then for other containers or replacing chain with
> then, I was suggesting that the definition for chain on promises is a
> little ambiguous with the existence of 'then'. 'chain' chains promises
> together. "then" also chains promises together, but with some extra stuff.
> It puts developers in the position of wondering, "so when should I use
> 'then'? Why should I use it instead of 'chain'?" Given that 'then' is what
> they'll likely want in 99.9% (sorry for my made up statistic) of
> situations, I think that in the case of promises, it should be on the
> burden of the 'chain' method to distinguish itself from 'then'–to define
> itself in relation to 'then'. I think its rather similar to the discussion
> on arrow functions. => is what someone wants so much more often that -> was
> left out. It was still possible, after all, its just normal functions, but
> it was decided that to aid comprehension, we would encourage the happy path.
> I'm not arguing 'chain' be removed. I'm convinced at this point its worth
> including, I'm just debating the method name here. Sorry if it's just
> bikeshedding at this point, but on the face of it, the two methods seem
> hard to distinguish, and while 'chain' might be a better name for some
> hypothetical monadic style, why not leave it up to some library to give the
> method a facelift. The same way that the promise API is being kept light,
> and will likely still be wrapped by things like the Q library for
> additional functionality, I expect some monadic focused library will be
> used if using promises in the monadic style. Worst case scenario, you just
> add an alias on the Promise prototype.

I agree with Russell that `chain` is a little ambiguous when juxtaposed
with `then. Around the time this conversation first kicked up I'd proposed
this API and referred to what Tab calls `chain` as the "one-step resolver
function". I still think `resolve` would be a pretty good, reasonably
self-documenting name -- especially compared to `chain`. You can describe
`then` as a recursive `resolve` and the difference should be obvious.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list