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: 19 Aug 2002 22:54:13 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <87fzxazi16.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> <87ofc5tgv0.fsf@zagadka.ping.de> <200208151953.g7FJruJ07836@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 1029790526 10917 127.0.0.1 (19 Aug 2002 20:55:26 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 19 Aug 2002 20:55:26 +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 17gtYZ-0002ps-00 for ; Mon, 19 Aug 2002 22:55:23 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17gu0A-0006Dr-00 for ; Mon, 19 Aug 2002 23:23:54 +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 17gtZb-00075B-00; Mon, 19 Aug 2002 16:56:27 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17gtXX-0006mn-00 for emacs-devel@gnu.org; Mon, 19 Aug 2002 16:54:19 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17gtXT-0006lM-00 for emacs-devel@gnu.org; Mon, 19 Aug 2002 16:54:18 -0400 Original-Received: from dialin.speedway42.dip19.dokom.de ([195.138.42.19] helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.10) id 17gtXT-0006lC-00 for emacs-devel@gnu.org; Mon, 19 Aug 2002 16:54:15 -0400 Original-Received: (qmail 2933 invoked by uid 1000); 19 Aug 2002 20:54:14 -0000 Original-To: rms@gnu.org In-Reply-To: <200208151953.g7FJruJ07836@wijiji.santafe.edu> Original-Lines: 94 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:6658 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6658 Richard Stallman writes: > There is a nearly standard macro out there called 'fluid-let' that > encapsulates the process completely. For example > > It looks like the right idea, though the name is confusing given that > it does not use fluids. Since the name fluid-let seems to be widely > known, perhaps fluids should be given a different name. Yes, we could do that. We could also try to generalize the fluids so that they can be 'local' to other contexts besides threads, like buffers or frames. Or, since we might use variables for buffer-local things, we could remove fluids and use the new features of variables to have real thread-local variables. > > 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? > > The point is, if the value that was saved by fluid-let came from a > buffer-local binding, it needs to restore that value into the same > buffer-local binding. If the value that was saved was from the > buffer-global binding, fluid-let needs to restore that value into the > buffer-global binding. The expansion of fluid-let needs extra code > both when saving and when restoring, to do this. I see, thanks. > What would need > to change in the above example when case-fold-search would be a > buffer-local variable? > > I am too overloaded to try to write the code (and I'd have to restudy > Scheme too). Is my explanation above clear? Yes. (I thought you might enjoy a little bit of programming here and there... :-) > This needs to be done for all variables, since any might perhaps be > made buffer-local. fluid-let could expand into the proper code for > this. We should probably tackle this as the larger, more general problem of working with arbitrary 'contexts' and variable-like 'entities' (variables, or fluids, or settable functions, or...) that can take on context-local values. Let's call these entities "locations". A particular context could then be specified by naming a location that will hold the 'current context'. For example, the location that points to the current buffer is used to specify the context for 'buffer-local' locations. The location that points to the current thread is used for thread-local variables. Thus, a location is characterized by its identity, and a reference to another location that holds its context. That reference is #f (or nil) when the location is currently global. The values of locations could be (conceptually) stored in a data base that is indexed with keys that are the combination of a location and another arbitrary value. 'Setting' a location LOC to the value VAL goes like this: when the context reference is #f, store VAL with the key (LOC . #f). When the reference is not #f, 'get' the value CTXT of the referenced location and store VAL with the key (LOC . CTXT). 'Getting' a location LOC means looking up the key (LOC . #f) when the context reference is #f, or first 'getting' the value CTXT of the referenced location and looking up the key (LOC . CTXT). There would also be a way to set the context reference of a location, of course. fluid-let would then remember the (LOC . CTXT) key and would swap according to that key. With the above model, we can have buffer-local variables where the curren-buffer variable is itself thread-local, for example. We could not have the situation where a variable is buffer-local in one thread and frame-local in another (that is, where the context reference of a location is itself stored in a location). Maybe we can generalize the model, or maybe we don't want to. The real implementation can use the optimizations that Emacs currently uses for its buffer-local etc variables. (I like the name 'with' better instead of 'fluid-let'. It goes with 'with-input-from-file', which sets the current-input-port in a dynamic extent, for example. But fluid-let is better known.) -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405