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
