That's a really good point. I hadn't been completely sold on the value of promises over callbacks before, but this seems like a very unambiguous advantage. I can't think of an obvious, clean way to do this with callbacks that doesn't go a long way toward simply re-implementing promises.
I imagine an advocate of core.async would argue that they have a good analog for canceled promises, though, namely closing channels. On the other hand, closed channels will still yield nil when read from; the procedures trying to read from a closed channel would need to check for that.
> I can't think of an obvious, clean way to do this with callbacks that doesn't go a long way toward simply re-implementing promises.
I may be misunderstanding your point, but you could name the callback function, and give the function object itself a "cancel()" method which alters its behavior to do nothing.
Yes, but that doesn't give you a great way to deal with attaching and canceling multiple callbacks simultaneously. If you want to perform several independent asynchronous actions after some other operation finishes, you have to collect them into a single giant callback in one location. And as you mention, the function has to keep track of some piece of mutable state in order to decide whether it's cancelled or not before firing off those operations. So why not give the function a mutable array of asynchronous operations to perform to begin with, which you can then add to at any time? And at that point, you already have a something very close to a promise.
I imagine an advocate of core.async would argue that they have a good analog for canceled promises, though, namely closing channels. On the other hand, closed channels will still yield nil when read from; the procedures trying to read from a closed channel would need to check for that.