Since the non-monadic way won, I don't know that it is worth arguing about why. But it is ergonomic issues much deeper than convenience, and much more important than compatibility with existing libraries -- even if those two were adequate considerations by themselves.
The behavior of promises was inspired (via Joule channels) by the behavior of logic variables in concurrent logic programming languages (FCP, Parlog, GHC, Vulcan, Janus, ToonTalk). An unbound logic variable, like a variable in logic, is a placeholder representing some ground value. Which ground value is yet to be determined. An unbound logic variable is not itself a ground value. Equating two logic variables means that the same ground value, whatever that is, must be the solution to both of them. A concurrent process waiting for a logic variable to be solved (fulfilled, bound) is not triggered when it is merely equated to another logic variable. The fact that the API is monad-like is an imperfect analogy I liked when it happened. But I now regret it because it has caused endless confusion. Likewise, I regret naming Ephemeron Tables "WeakMaps" (although anything is better than "Ephemeron Tables") because people tried to read into it a stronger analogy to weak references than was meant. Having a promise become its value, as in E, would also only be possible if they were non-monadic, because it would make them *more* like concurrent logic programming logic variables. To avoid a rehash of things we have already argued to exhaustion, I refer everyone to previous discussions. Please only respond here if you have something to say that has not already been said in those previous discussions, or if you'd like to provide links to those previous discussions. -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss