all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tom Tromey <tromey@redhat.com>
To: Daniel Colascione <dancol@dancol.org>
Cc: Emacs discussions <emacs-devel@gnu.org>
Subject: Re: [PATCH 06/10] add most lisp-level features
Date: Mon, 13 Aug 2012 08:51:08 -0600	[thread overview]
Message-ID: <87d32u7smb.fsf@fleche.redhat.com> (raw)
In-Reply-To: <502467BF.2020301@dancol.org> (Daniel Colascione's message of "Thu, 09 Aug 2012 18:45:35 -0700")

>>>>> "Daniel" == Daniel Colascione <dancol@dancol.org> 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	other threads:[~2012-08-13 14:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-09 19:41 [PATCH 06/10] add most lisp-level features Tom Tromey
2012-08-10  1:45 ` Daniel Colascione
2012-08-13 14:51   ` Tom Tromey [this message]
2012-08-13 20:46     ` Stefan Monnier
2012-08-13 21:02       ` Tom Tromey
2012-08-14  1:13         ` Stefan Monnier
2012-08-14 14:46           ` Tom Tromey
2012-08-14 15:05             ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d32u7smb.fsf@fleche.redhat.com \
    --to=tromey@redhat.com \
    --cc=dancol@dancol.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.