The Paradox of Partial Parametricity
Tab Atkins Jr.
jackalmage at gmail.com
Sun May 26 08:14:18 PDT 2013
On Sun, May 26, 2013 at 7:30 AM, Russell Leggett
<russell.leggett at gmail.com> wrote:
> 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
> hypothetical scenario.
The fact that we can make it monadic is just a bonus; any time you see
"monad" just think "container++" - it's just a proven useful bit of
structure on top which makes it easy to work with the values inside
the container. (It's a bit more abstract than that, of course, but
thinking in terms of containers works for many monads, and helps guide
understanding toward the more abstract notion.)
The use-cases for "generic container" promises have been explored.
Many types of promises are fairly interchangable, because all they're
doing is providing a tiny async barrier between you and the result,
and so collapsing them together isn't very objectionable. Some types
of promises, though, represent something significant and different -
significant delays, significant computation, etc. (A big class of
these "significant and different" promises will be lazy promises,
which don't do their computation at all until someone registers a
callback for the first time.) You don't want to automatically resolve
them just because they were handed to you wrapped in another promise,
or at least, you don't always want this; sometimes, you'll want to
instead work with it *as a promise*, so you're not incurring extra
delay until you actually need their inner value.
> 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
> expectations about what chain means. For most people, they with just think
> of wrapping something for method chaining.
I don't think single-unwrapping is so painful as to require a painful
name to go along with it. Plus, given that we can make it monadic,
the value comes from using a name generic enough to be useful for
other monadic structures, so as we add more, the network effects
accrue automatically (rather than requiring a library that just adds a
bunch of aliases to various classes).
More information about the es-discuss