Yep. There was some fairly famous pressure from FP folks to try and give Promises a more standardized type behavior, which was mostly deflected because of a strong desire for Promises/A+ to conform to, and not break, previous similar patterns and Promises/A+ implementations (jQuery-v2.Deferred, Bluebird’s Promises, for example). That pushback, in fact, was part of the inspiration for Fantasy Land.

In JS, there are now a bunch of great, Fantasy-Land compliant algebraic implementations: Future, Fluture, and Task, and so on. I think it’s still interesting to work with Promises and to examine how they can be made to conform to some of those requirements, exposing common behaviors. Which is why I generally use them in examples (since people are familiar with Promises, but not necessarily algebraic types: myself included!) But in production/real coding, it’s probably best to stick to well-tested/optimized types that explicitly try to work to FL’s spec instead of using Promises if that’s the sort of coding you want to do.