The Paradox of Partial Parametricity
russell.leggett at gmail.com
Tue May 28 09:24:49 PDT 2013
On Tue, May 28, 2013 at 9:55 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
> On Mon, May 27, 2013 at 9:53 AM, Russell Leggett
> <russell.leggett at gmail.com> wrote:
> > On Mon, May 27, 2013 at 11:04 AM, Tab Atkins Jr. <jackalmage at gmail.com>
> > wrote:
> >> On Mon, May 27, 2013 at 7:29 AM, Russell Leggett
> >> <russell.leggett at gmail.com> wrote:
> >> > I'm just going to go ahead and play stupid here. Why is it called
> >> > 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
> >> > 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
> > additional functionality)? I agree that naming abstract operations is
> > 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
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss