Provide mechanism to attach success callbacks to promises

[tmccombs]

Many promise libraries provide a way to call additional functions when the promise is fulfilled (for example the then method on jQuery deferred objects).

You can kind of do this with futures with ptrees, but as far as I can tell there isn't a good way to do it with delays.

It would be possible to implement this feature from user code or as another library if promises were extensible, specifically if the fulfill-object function was a generic function and exported and the classes for promise, delay, and future were exported. But that is not the case.

[lmj]

It seems that the practice of attaching callbacks to promises is usually associated with async frameworks where one doesn't have direct access to threads. Where threads are available, like in many CL implementations, one can simply write

(future
  (heavy-operation)
  (notify-done))

The practical translation of this into JavaScript involves splitting up the code with callbacks. Callbacks seem more like an async thing than a promise thing. The threading model that CL implementations offer -- the one that lparallel uses -- is true multithreading, not async. (There are CL projects that provide async functionality, but they do so through foreign libraries.)

Async promises don't translate well into CL. If the purpose of these callbacks is to tie promises together, then we run into the blocked-worker problem that is solved by ptrees. If the purpose is notification, then one can just call a notify function directly, like in the code above. We might want to attach a notification to a promise that we didn't create, but this also seems unnecessary -- we can just place the code after a force call. Native threads naturally address issues that are elsewhere handled by callbacks.

Assuming that one really wants these callbacks, should lparallel promises be flexible enough for an end-user to implement them? It's not quite as simple as making fulfill-object into a method, though with some changes it could be a suitable hook. As a practical matter, though, lparallel avoids defmethod where possible because of this bug in SBCL. But putting that aside, I still envisioned lparallel promises as being more low-level than what is being proposed. I think a layer on top of lparallel promises would be more suitable than exposed method hooks.

I don't follow the sentence "You can kind of do this with futures...", so I may have misunderstood something (or everything).

[lmj]

Closing due to inactivity, without prejudice for further discussion.