From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Tom Tromey Newsgroups: gmane.emacs.devel Subject: Re: [PATCH 06/10] add most lisp-level features Date: Mon, 13 Aug 2012 08:51:08 -0600 Message-ID: <87d32u7smb.fsf@fleche.redhat.com> References: <87a9y3etto.fsf@fleche.redhat.com> <502467BF.2020301@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1344869498 24916 80.91.229.3 (13 Aug 2012 14:51:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 13 Aug 2012 14:51:38 +0000 (UTC) Cc: Emacs discussions To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 13 16:51:39 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1T0vzS-0001l9-9P for ged-emacs-devel@m.gmane.org; Mon, 13 Aug 2012 16:51:34 +0200 Original-Received: from localhost ([::1]:36684 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0vzR-0001fr-8w for ged-emacs-devel@m.gmane.org; Mon, 13 Aug 2012 10:51:33 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0vzF-00016r-Am for emacs-devel@gnu.org; Mon, 13 Aug 2012 10:51:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1T0vz5-0002gM-Ey for emacs-devel@gnu.org; Mon, 13 Aug 2012 10:51:21 -0400 Original-Received: from mx1.redhat.com ([209.132.183.28]:59856) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1T0vz5-0002g0-5z for emacs-devel@gnu.org; Mon, 13 Aug 2012 10:51:11 -0400 Original-Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q7DEp9ed025073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 13 Aug 2012 10:51:09 -0400 Original-Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q7DEp8ZR022198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 13 Aug 2012 10:51:08 -0400 X-Attribution: Tom In-Reply-To: <502467BF.2020301@dancol.org> (Daniel Colascione's message of "Thu, 09 Aug 2012 18:45:35 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.132.183.28 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:152487 Archived-At: >>>>> "Daniel" == Daniel Colascione 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