Re: ELisp futures and continuations/coroutines

[SAKURAI Masashi]

At Thu, 19 May 2011 17:51:20 -0500,
Ted Zlatanov wrote:
> :
> It's a good library, but maybe too complicated for general use.  I don't
> know how the maintainers feel about anaphoric macros and chained
> futures.  The resulting code, while neat, is IMO hard to understand if
> you don't understand the underlying macros.

I employed the anaphoric macros to simulate the method chains in
conventional OOP languages or the "do" syntax in Haskell. I feel
that it is not so good too. I would learn the better ideas.

* JavaScript (JSDeferred):
    http.get("http://example.com/";).
    next(function(result) {
        alert(result);
    });

* Haskell:
    main = do x <- getContents
              putStr x

* elisp (deferred.el):
    (deferred:$
      (deferred:url-retrieve "http://www.gnu.org";)
      (deferred:nextc it
        (lambda (buf)
          (insert (with-current-buffer buf (buffer-string)))
          (kill-buffer buf))))

> Also, the library does a lot more than futures, and I think it would be
> nice to separate just the futures (the `deferred' defstruct).  But the
> way they are implemented currently, the queue implementation is implicit
> in the future definition itself.

Yes. The library deferred.el focuses on just supporting asynchronous
callback programing. So, it is different from the "future" type that
you mentions in some aspects. Although on the higher abstract layer,
those ideas and implementations may be identical, the users like 
practical ones.

It seems that many JavaScript developers like the word "deferred", and
that the Java, C++ and other functional languages developers like
"future".


> I think with lexical closures Emacs is getting closer to true
> concurrency, which is better than simulating it in a single-threaded
> way.  I like your approach, it's just (like fsm.el) that it's a very
> specific way of doing things that doesn't fit with the rest of ELisp
> code, so I don't think it should be the *standard* way to do futures or
> continuations.

I see. I think the developers who are familiar to JavaScript's
deferred like deferred.el.


> SM> I would like to include deferred.el in the Emacs package.
> 
> I'm in favor, it's a good library and more useful in the core than in
> the GNU ELPA.

Thank you. I'm encouraged.


--
SAKURAI, Masashi (family, given)