Re: ELisp futures and continuations/coroutines

[Thien-Thi Nguyen]

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

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

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

A "future type" w/o this detail well-defined is no better than
a simple closure (IMHO) because it has no concept of time / timing.

Since invocation must be well-defined, so must the reception and
stashing of the returned value(s) be done in a coordinated way.

I think the "hello world" (demonstrating minimal sufficiency)
of such a system is countdown timer.

   I'd rather establish a futures API:

   - create a future
   - is it done?
   - get result
   - inspect thrown error, if any

   which is simple, obviously, but it's essential so all the
   implementations that use it speak the same language.

The answer to "is it done" is "never", if it never is kicked, tickled,
invoked, prodded, probed, or otherwise moved to action.

   I like the defstruct because it's simple

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

   (defstruct future callback errorback status value)
   [...]

Keep going!

   If the above looks OK I can finish the implementation (error handling in
   `future-call' and around the callback/errorback invocations).  Then any
   library can use ":include future" to add its own details on top of the
   `future' defstruct.

Minimalism is nice, but i suppose i like a more full-featured "future type",
one that can self-terminate, for example.  Conniving computers, grumble...
(i'll have to dig up and post some old fsm toys -- get a dozen of them going
at once and you'll see what i mean :-D).

-- 
a sig, not big, i fig, you dig?