From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp and Guile Date: 14 Aug 2002 20:50:11 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <87ofc5tgv0.fsf@zagadka.ping.de> References: <200207200035.g6K0ZAb27891@aztec.santafe.edu> <200207212015.g6LKF4c00874@aztec.santafe.edu> <200207251807.g6PI75d07615@aztec.santafe.edu> <874renlito.fsf@zagadka.ping.de> <200207271853.g6RIre710837@aztec.santafe.edu> <200207310554.g6V5ssc16508@aztec.santafe.edu> <200208021743.g72HhkX01596@aztec.santafe.edu> <200208110355.g7B3tk306295@wijiji.santafe.edu> <200208121705.g7CH5rI06514@wijiji.santafe.edu> <200208132247.g7DMl6w07259@wijiji.santafe.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1029351021 18545 127.0.0.1 (14 Aug 2002 18:50:21 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 14 Aug 2002 18:50:21 +0000 (UTC) Cc: neil@ossau.uklinux.net, raeburn@raeburn.org, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17f3Di-0004oq-00 for ; Wed, 14 Aug 2002 20:50:14 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17f3cq-00040o-00 for ; Wed, 14 Aug 2002 21:16:12 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17f3Ed-0001cc-00; Wed, 14 Aug 2002 14:51:11 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17f3Di-0001SC-00 for emacs-devel@gnu.org; Wed, 14 Aug 2002 14:50:14 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17f3Dg-0001Qu-00 for emacs-devel@gnu.org; Wed, 14 Aug 2002 14:50:14 -0400 Original-Received: from dialin.speedway42.dip157.dokom.de ([195.138.42.157] helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.10) id 17f3Df-0001QQ-00 for emacs-devel@gnu.org; Wed, 14 Aug 2002 14:50:12 -0400 Original-Received: (qmail 2663 invoked by uid 1000); 14 Aug 2002 18:50:11 -0000 Original-To: rms@gnu.org In-Reply-To: <200208132247.g7DMl6w07259@wijiji.santafe.edu> Original-Lines: 54 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:6539 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6539 Richard Stallman writes: > Having now seen the R5RS description of dynamic-wind, I see it is a > very low-level mechanism. For the sake of using dynamic-wind for > dynamic variable bindings, it would be convenient to have a function > to swap in bindings and a function to swap out bindings. Then > when you write calls to dynamic-wind, you would call these functions, > not manipulate bindings directly. There is a nearly standard macro out there called 'fluid-let' that encapsulates the process completely. For example (fluid-let ((case-fold-search #f)) (search-forward ...)) would expand to (let ((body (lambda () (search-forward ...))) (outer #f)) (define (swap) (let ((t outer)) (set! outer case-fold-search) (set! case-fold-search t))) (dynamic-wind swap body swap)) > These functions could also have code for correct interaction with > buffer-local bindings and frame-local bindings. Does this refer to the fact that buffer-localness and frame-localness are not completely independent from dynamic scoping? What would need to change in the above example when case-fold-search would be a buffer-local variable? Or do you intend to implement buffer-localness (etc) itself by using the functions? These functions would then need to run when the current buffer changes. But dynamic-wind does not react to changes to the current buffer so we can't use it to run the swapping functions at the right times, I would say. Can you elaborate? > Suppose that Guile could run arbitrary code before and after the > variable reference, for effect only, and the variable reference > itself would always occur normally. This would not encourage people > to use variables for jobs that ought to be done by functions, but > would permit implementation of this optimization, and various sorts > of forwarding. What do you think of this idea? I think it's very nice! I have sent a smallish proposal to the guile-devel list about preparing us for specially constructed 'non-dumb' variables that need to be accessed with scm_variable_ref and scm_variable_set_x. We can then add whatever code is needed to these two functions and be sure that they wont be side-stepped. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405