emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 06/10] add most lisp-level features


From: Tom Tromey
Subject: Re: [PATCH 06/10] add most lisp-level features
Date: Mon, 13 Aug 2012 08:51:08 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux)

>>>>> "Daniel" == Daniel Colascione <address@hidden> writes:

Tom> I'm still undecided about *default-special-bindings* (which I did not
Tom> implement).  I think it would be more emacs-like to capture the let
Tom> bindings at make-thread time, but IIRC Stefan didn't like this idea
Tom> the first time around.

Daniel> I'm with Stefan here. Capturing the bindings at thread-creation
Daniel> time makes the binding in effect for a thread worker hard to
Daniel> reason about. Say Gnus binds *foo* and calls into bar-lib, which
Daniel> internally uses threads. bar-lib's thread worker has no idea
Daniel> *foo* is bound, and if a non-Gnus caller uses bar-lib, *foo*
Daniel> won't be bound. I feel like this approach would lead to
Daniel> hard-to-find bugs.

The reason I am not totally sold on this approach is that Emacs already
uses dynamic binding in most code, and it is actually used.

For example suppose you were reworking some code to run in a separate
thread.  You can be faced with the mirror image of the above problem:
your callers may have some bindings in effect that you need to capture,
but you don't know which ones.

Or to put it another way, you already have the "hard to reason about"
problem any time you write in Emacs Lisp.  Why should make-thread have
different semantics from other primitives?

Yet one more observation here.  The Bordeaux approach lets you specify
which bindings to capture.  It seems to me that some such mechanism is
necessary, at the very least.  Otherwise, passing a local variable into
a thread seems difficult, unless you assume that only lexical-binding:t
code will want to make threads.  I guess it could be done with
backquote, kind of ugly though.

It seems weird to have this set the global "wrongly":

   (let ((local 23))
      (make-thread (lambda () (setq global local))))

Especially if you wrap this kind of thing up some macro, say
"with-worker-thread" or the like.

I'm not totally convinced by these ideas either though.  Maybe
everything important really will use lexical binding.

Tom



reply via email to

[Prev in Thread] Current Thread [Next in Thread]