From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.lisp.guile.devel Subject: Re: %nil once again Date: Mon, 20 Jul 2009 05:15:44 -0400 Message-ID: References: <4A5F2F8A.5040108@domob.eu> <8763drbv07.fsf@arudy.ossau.uklinux.net> <4A603E36.7080100@domob.eu> <87ab30bk8p.fsf@arudy.ossau.uklinux.net> <4A63778E.3010109@domob.eu> <87skgsa0xz.fsf@arudy.ossau.uklinux.net> <4A6426FA.6050803@domob.eu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v935.3) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248083807 5808 80.91.229.12 (20 Jul 2009 09:56:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 20 Jul 2009 09:56:47 +0000 (UTC) Cc: Andy Wingo , guile-devel , Neil Jerram To: Daniel Kraft Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon Jul 20 11:56:39 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MSpbr-0003lW-DH for guile-devel@m.gmane.org; Mon, 20 Jul 2009 11:56:39 +0200 Original-Received: from localhost ([127.0.0.1]:55847 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MSpbq-0002OT-SS for guile-devel@m.gmane.org; Mon, 20 Jul 2009 05:56:38 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MSpbn-0002Mt-7m for guile-devel@gnu.org; Mon, 20 Jul 2009 05:56:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MSpbj-0002MK-Jc for guile-devel@gnu.org; Mon, 20 Jul 2009 05:56:34 -0400 Original-Received: from [199.232.76.173] (port=52198 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MSpbj-0002MH-DF for guile-devel@gnu.org; Mon, 20 Jul 2009 05:56:31 -0400 Original-Received: from [76.119.237.235] (port=64819 helo=raeburn.org) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MSpbi-0005ML-MY for guile-devel@gnu.org; Mon, 20 Jul 2009 05:56:31 -0400 Original-Received: from [10.0.0.172] (squish.raeburn.org [10.0.0.172]) by raeburn.org (8.14.3/8.14.1) with ESMTP id n6K9FiDn004098; Mon, 20 Jul 2009 05:15:44 -0400 (EDT) In-Reply-To: <4A6426FA.6050803@domob.eu> X-Mailer: Apple Mail (2.935.3) X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. X-Greylist: delayed 2287 seconds by postgrey-1.27 at monty-python; Mon, 20 Jul 2009 05:56:30 EDT X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:8896 Archived-At: On Jul 20, 2009, at 04:12, Daniel Kraft wrote: >>> No, I don't think there is. `let' can't operate on function slots. >> Not in the main emacs lisp implementation. However, cl-macs.el >> provides an "flet" macro that does work on function slots; it uses >> the "letf" macro which expands to include a use of unwind-protect >> to do its dirty work. > > But that's not part of the real "elisp semantics", and so if we > don't want to include this as a genuine extension into Guile's > compiler, we don't have to use the fluids for function slots. True. > With unwind-protect and friends one can, just like in emacs, > implement this functionality, even without a fluid implementation. Yes... though it means the elisp implementation wouldn't be able to cleanly support a multithreaded implementation that makes "flet" possible to implement safely. If we want multiple threads, we probably do want thread-safe flet, I would guess. > However, if you agree that this would be a useful feature (dynamic > scoping of functions) I can of course implement this as an extension > to elisp...? I agree that it might be of use sometimes, but am not > convinced it is really "necessary". I haven't looked into what it's needed for in great detail, but it does seem to get used in some places (gnus, mh-e, org, vc-rcs, ...). I don't know if we'll get to multithreaded elisp (I kind of hope so) or if we'll care about having a thread-safe flet (???), or thread-safe versions of whatever other interesting things unwind-protect might be getting used for. Ken