Re: ELisp futures and continuations/coroutines

[Ted Zlatanov <tzz@lifelogs.com>]

On Fri, 03 Jun 2011 22:59:48 +0900 SAKURAI Masashi <m.sakurai@kiwanami.net> wrote: 

SM> At Tue, 24 May 2011 21:07:50 -0500,
SM> Ted Zlatanov wrote:
>> :
>> Also please see the discussion in this thread about url-future.el.  If
>> you can consider augmenting that defstruct instead of using the one in
>> deferred.el, it would be nice so we're all speaking the same data
>> language.  I asked the same of Thien-Thi Nguyen for fsm.el.  But it's
>> not a requirement for inclusion in the GNU ELPA and you don't have to do
>> it.

SM> About the "future" type for the just url-fetch function, I think it is
SM> good enough to transfer values asynchronously to the waiting function.
SM> However, I think it is somewhat primitive to construct general
SM> asynchronous programs.

The future type is intentionally a simple pure data type.  It can be
extended with `defstruct'.  Is the data type missing something you need?
Can you convert concurrent.el to derive its data type from the
url-future struct and use the url-future-* functions, or is there
something blocking that conversion?  When I looked at concurrent.el, the
data type it uses was very similar to the url-future defstruct.

SM> While I'm not a researcher for the concurrent programing,
SM> investigating such other async libraries, I found that asynchronous
SM> programing needs at least following two functions:

SM> 1) sequential connecting
SM> 2) waiting for async tasks done (all of them or the earliest one).

SM> One can define many other aspects of async programing.
SM> Ex. composition of tasks, error handling, canceling, propagating
SM> values, adding tasks after executed, restarting tasks, notifying
SM> progress and so on[3].

Sure, but all of these are functional requirements.  url-future.el only
addressed the "futures" protocol, so we can speak a common data
language.  It doesn't provide any actual async support.  That's the job
for concurrent.el and deferred.el among others.

SM> Though concurrent.el has some patterns those were implemented for my
SM> applications, of course, it doesn't cover all patterns. According to
SM> other languages and some books, STM, Agent, Actor, Reentrant Lock and
SM> Read-Write Lock are argued as concurrent programing.

I'm not sure how much of that is needed in Emacs.  Perhaps these needs
will become more apparent when the concurrency branch is merged, though
I have no idea when that will hapen.

SM> Last, if my experience of development of deferred.el and concurrent.el
SM> would help the Emacs's advance, I would be happy. I don't mind if
SM> the libraries will be added to GNU ELPA or Emacs, even the maintainers
SM> write a subset code from scratch.

You need to sign the assignment papers.  One of the Emacs maintainers
can help you with that.  I think assign@gnu.org is the general contact
point for any copyright assignment questions.

Ted