From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Emacs Lisp and Guile Date: Tue, 20 Aug 2002 18:12:06 -0600 (MDT) Sender: emacs-devel-admin@gnu.org Message-ID: <200208210012.g7L0C6x10035@wijiji.santafe.edu> 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> <87fzxazi16.fsf@zagadka.ping.de> Reply-To: rms@gnu.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1029889326 19358 127.0.0.1 (21 Aug 2002 00:22:06 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 21 Aug 2002 00:22:06 +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 17hJG8-000527-00 for ; Wed, 21 Aug 2002 02:22:04 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17hJiH-0002NX-00 for ; Wed, 21 Aug 2002 02:51:09 +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 17hJHG-0007Do-00; Tue, 20 Aug 2002 20:23:14 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17hJ6p-0004vR-00 for emacs-devel@gnu.org; Tue, 20 Aug 2002 20:12:27 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17hJ6e-0004rl-00 for emacs-devel@gnu.org; Tue, 20 Aug 2002 20:12:24 -0400 Original-Received: from pele.santafe.edu ([192.12.12.119]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17hJ6d-0004qY-00; Tue, 20 Aug 2002 20:12:15 -0400 Original-Received: from wijiji.santafe.edu (wijiji [192.12.12.5]) by pele.santafe.edu (8.11.6+Sun/8.11.6) with ESMTP id g7L0CT512388; Tue, 20 Aug 2002 18:12:29 -0600 (MDT) Original-Received: (from rms@localhost) by wijiji.santafe.edu (8.11.6+Sun/8.9.3) id g7L0C6x10035; Tue, 20 Aug 2002 18:12:06 -0600 (MDT) X-Authentication-Warning: wijiji.santafe.edu: rms set sender to rms@wijiji using -f Original-To: mvo@zagadka.ping.de In-Reply-To: <87fzxazi16.fsf@zagadka.ping.de> (message from Marius Vollmer on 19 Aug 2002 22:54:13 +0200) 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:6698 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6698 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. That would be much more inconvenient to use, so it is not a good idea. Let's make these variables accessible simply *as variables*. > 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". I think it is better if we do not generalize that far. That extra generalization makes things much more complicated and gives little extra power. I think we should start by handling just variables, and see how convenient we can make that limited feature, 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. That is possible but it would make things much slower. It makes no sense to consider such a big slowdown for an unimportant generalization. The speed is more important than the extra generality. So this is not a good idea at all. '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). This is totally unnatural for variables. We want the ordinary Scheme value of the variable `foo' to be the proper value from whichever binding is current, even when `foo' has buffer-local bindings. Please focus on implementing this feature for variables in the most natural and efficient way you can.