@slavsquatch: as mentioned by @Riwsky, one of the main reasons for having promises in Reason is interop.
However, something often overlooked is that direct interop with JS promises doesn’t mean we have to make the same mistakes that JS made. Using the type system, we can force JS promises to be sound, force explicit error handling, and separate exceptions from other errors. That addresses soundness and points (3) and (4). See Repromise for an example implementation that does this:
On BuckleScript, Repromise is implemented, internally, directly as JS promises for full interop. It also has a pure-Reason implementation, that can be used on native and with BuckleScript. The pure-Reason implementation inherently doesn’t need to make any tradeoffs for JS interop
Cancelation is pretty tricky to get right, once one starts considering diverse use cases. But, if we have a good design for it, we can implement cancelation, whether on top of JS promises, or in pure Reason. The same goes for lazy promises.
Concerning naming, the concept of promises isn’t limited to only JS, and we shouldn’t assume that the buggy JS implementation is even a good example of promises. I say we keep the name. But if this is going to be a stumbling block for learning, we can switch to a synonym like futures or deferreds. IMO, if we are going to have interop with promises, we should call the Reason side of it promises as well, even if the API is a bit different.
In the end, promise/future/deferred are all names that are used by various languages and libraries for what they chose to implement from the same promise/future/deferred design space. By comparison, lots of languages have various kinds of maps in their libraries. We still refer to most of them as maps, even while keeping their important differences in mind.