Re: A Challenge Problem for Promise Designers

On Fri, Apr 26, 2013 at 1:51 PM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Fri, Apr 26, 2013 at 1:45 PM, Domenic Denicola
> <domenic@domenicdenicola.com> wrote:
> > From: Tab Atkins Jr. [jackalmage@gmail.com]
> >> Shorter me: this is why I keep asking people who want flattening to
> actually provide an example of where flattening is useful, that isn't (a)
> assimilation, (b) a result of weird language semantics from some non-JS
> language, or (c) an authoring error.
> >
> > Since (multi-level) flattening only occurs for assimilation (per
> Promises/A+ 1.1), it appears we have been talking past each other. All
> examples of multi-level flattening will necessarily be examples of
> assimilation.
>
> In that case, HUZZAH!  We've solved the problem!


We may have.

When I argue for default flattening (#0 in my "What Are We Arguing About")
and you argue against, you claim default flattening is not monadic, which I
agree with. But then you go on to explain as "monadic" a semantics that
seems like default flattening to me. I am curious if you could define what
you mean by "monadic". I don't much care if we call a promise system
"monadic" or not, but let's not let a disagreement on this term obscure a
possible agreement on what promises should do.

As I made clear in my "What Are We Arguing About" email, I want to separate
the argument about default flattening (#0) from the argument about whether
promises-for-promises are possible (#1), and from arguments about thenables
and assimilation (#2,#3,#4).

AFAICT, leaving aside operations that would explicitly create
promises-for-promises, i.e., "fulfill" (aka "accept"), I don't see how it
is possible to create promises-for-promises with the remaining operations
you and I seem to agree on: Q(x) (aka "Future.resolve(x)"), "then",
"resolve", "reject". If promise-for-promises cannot be made in the first
place, then no recursive unwrapping is required to take them apart.
Specifically, assimilation aside and API details aside, what about Q do you
disagree with, if anything?

If we can narrow our remaining disagreements down to #1..#7, that would be
great progress. Yes, #1..#7 will still be a lot of work, but great progress
nonetheless. And I will leave to you and other to fight about what is and
isn't called "monadic" ;).




>  Assimilation is not
> a troublesome issue; if that works best when done recursively, go for
> it.  Presumably, the reason it works best when done recursively is
> that if the value passed between multiple non-assimilating promise
> concepts, it might have gotten multi-wrapped, once for each promise
> concept (or maybe more than once for each, if the layers are separated
> by other types of promises).  So, it's more useful to just assume that
> multi-wrapped thenables were done accidentally, and should be fully
> flattened.
>
> If that's all we need to do, and we can have an explicit assimilation
> function in the standard that takes arbitrary thenables (per the
> Promises/A+ spec), then we can leave .then() alone and give it the
> correct monadic semantics.  It's very difficult to accidentally get
> double-wrapped within a single library with proper semantics, and
> doing so indicates a fundamental logic error and so *should* give
> funky results, rather than having the error accidentally papered over.
>
> ~TJ
>



-- 
Text by me above is hereby placed in the public domain

  Cheers,
  --MarkM