Re: ELisp futures and continuations/coroutines

[SAKURAI Masashi]

At Fri, 03 Jun 2011 11:06:22 -0500,
Ted Zlatanov wrote:
> :
> 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.

I have understood "speaking a common data language" you mentioned.
OK. I see. I would try to modify deferred.el to fit the data type,
after I check the code of the url-fetch.

> 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.

I see.

Recently I'm interesting in the Emacs as an application runtime environment.
So, I'm also interesting in the thread 'Emacs as a desktop environment'.

> 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 address@hidden is the general contact
> point for any copyright assignment questions.

I sent my request to address@hidden in last month, and
I'm waiting for assignment papers from gnu.org. 

--
SAKURAI, Masashi (family, given)