Re: ELisp futures and continuations/coroutines

[Ted Zlatanov]

On Fri, 20 May 2011 03:23:57 +0200 Thien-Thi Nguyen <address@hidden> wrote: 

TN> () Ted Zlatanov <address@hidden>
TN> () Thu, 19 May 2011 18:48:49 -0500

TN>    Why tie futures to fsm.el or deferred.el specifically?  That seems like
TN>    an implementation detail.

TN> Well, one important detail, whether you consider it implementation
TN> or design, is who kicks the evaluation (and when).  In the case of
TN> fsm.el, this is done by either a timer or from process input.

Yes, but deferred.el does it with a timer-triggered queue drain, storing
the next deferred item in the current one, and the concurrency branch
might do it with a separate thread.  These implementation details
obscure the purpose of the "future" type: to hold a potential value.

TN> A "future type" w/o this detail well-defined is no better than
TN> a simple closure (IMHO) because it has no concept of time / timing.
...
TN> Minimalism is nice, but i suppose i like a more full-featured "future type",
TN> one that can self-terminate, for example.  Conniving computers, grumble...
TN> (i'll have to dig up and post some old fsm toys -- get a dozen of them going
TN> at once and you'll see what i mean :-D).

Why should a future type encapsulate any time knowledge?  The whole
point is that you don't know when and if it will be available.

You could derive a expected-future which will have some knowledge of
when it might have the data.  A self-managed-future could run its own
functions.  And so on.  But I really want a clean, simple API that can
be used by any library.

Let's get this done, simple though it is, and then see how it will
integrate with fsm.el and deferred.el.  I really think it will benefit
everyone to start simple.

TN> Yes, [defstruct is] much cleaner than fsm's plist munging, but (as i
TN> tried to express above), that is just the shape of the sail and not
TN> the motion of the boat.

Heh heh.  I guess we're close to land then.

TN> Keep going!

The below adds a way to cancel a future.  I think error handling is all
that's left unsaid.

Ted

#+begin_src lisp
(defstruct future callback errorback status value)

(defun future-done-p (future)
  (future-status future))

(defun future-errored-p (future)
  (eq (future-status future) 'error))

(defun future-cancelled-p (future)
  (eq (future-status future) 'cancel))

(defun future-finish (future &optional status)
  (unless (future-done-p future)
    (setf (future-status future) (or status t))
    (when (future-callback future)
      (funcall (future-callback future) future))))

(defun future-errored (future error)
  (unless (future-done-p future)
    (setf (future-status future) 'error)
    (when (future-errorback future)
      (funcall (future-errorback future) future error))))

(defun future-call (future)
  (unless (future-done-p future)
    (let ((ff (future-value future)))
      (when (functionp ff)
        ;; TODO: needs error handling
        (setf (future-value future)
              (funcall ff))))
    (future-finish future)))

(defun future-cancel (future)
  (unless (future-done-p future)
    (future-finish future 'cancel)))

#+end_src