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: 05 Aug 2002 18:08:24 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: 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> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1028563709 2528 127.0.0.1 (5 Aug 2002 16:08:29 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 5 Aug 2002 16:08:29 +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 17bkPD-0000ef-00 for ; Mon, 05 Aug 2002 18:08:27 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17bkjv-0003Vo-00 for ; Mon, 05 Aug 2002 18:29:51 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17bkPp-0000jx-00; Mon, 05 Aug 2002 12:09:05 -0400 Original-Received: from krusty.dt.e-technik.uni-dortmund.de ([129.217.163.1] helo=mail.dt.e-technik.uni-dortmund.de) by fencepost.gnu.org with esmtp (Exim 3.35 #1 (Debian)) id 17bkPf-0000iU-00; Mon, 05 Aug 2002 12:08:56 -0400 Original-Received: from burns.dt.e-technik.uni-dortmund.de (burns.dt.e-technik.uni-dortmund.de [129.217.163.19]) by mail.dt.e-technik.uni-dortmund.de (Postfix) with ESMTP id 92EB1A3831; Mon, 5 Aug 2002 18:08:54 +0200 (CEST) Original-Received: by burns.dt.e-technik.uni-dortmund.de (Postfix, from userid 520) id D9AE3F42C; Mon, 5 Aug 2002 18:08:24 +0200 (CEST) Original-To: rms@gnu.org In-Reply-To: <200208021743.g72HhkX01596@aztec.santafe.edu> Original-Lines: 85 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1 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:6296 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6296 Richard Stallman writes: > Emacs Lisp has hundreds of dynamic variables, whose names are > documented, that user programs examine, set, and bind. It would be > clumsy and impractical to hide each of these variables behind a > separate function in Scheme. It would be practical but clumsy to > have a few Scheme functions for accessing and binding Lisp > variables. That would make Scheme very inconvenient to use, > compared with Emacs Lisp. Agreed. > What about exporting all Elisp variables to Scheme as settable > functions? For example > > (set! (require-final-newline) 'ask) > > This would lead to a divergence between Scheme variables and Lisp > variables, but I don't think this is bad. > > I think it is ugly--variables should remain variables. I do like it. It would also make it trivial to include the optimizations that you talk about below. When Elisp variables should appear as Scheme variables we would need to implement a new kind of variable in the core of Guile (which is no argument against doing it). Right now, a variable is a strictly passive data container. You can't intercept accesses to it. A variable reference is a direct reference to memory, not a function call. We would have to change this model to also allow 'active' variables that can run arbitrary code when they are accessed. Whenever some code uses a variable, it can either be a passive variable or an active variable. It needs to treat the two cases differently since we want to make use of the extra performance that passive variables allow. We would need to make sure that the distinction between 'passive' and 'active' variables can be made at compile time, but that should be doable as well. This makes 'active' variables pretty similar to symbol macros, so maybe we should just use them. > There should be a list of current local contexts, which the user > program can use for different purposes. Emacs would use one for the > current buffer's bindings, and one for the current frame's bindings. Yes, that should be no problem. > I'm afraid this might turn out to be expensive and it is not a good > solution in a multi-threaded system. > > It does not have to be expensive. Although Emacs is not > multi-threaded, it has an optimization for this: a variable's > buffer-local bindings are not swapped until you try to access the > variable. Runnning another thread for a short time, if it does not > access many of these variables, won't have to swap many of them. This assumes that only one thread is running at a time. It wouldn't work for a machine with multiple CPUs where threads can run at the same time and the concept of a "thread switch" does not exist. Maybe we don't want to care about this, which I would be very happy with. > Fluids > provide thread-local storage and dynamic-wind is used to swap values > in and out of these locations to establish dynamic contexts. > > [...] > Or are you saying that dynamic-wind can be used either to swap values > in and out of a variable, or to swap values in and out of a fluid? That's what I wanted to say. A fluid can have one value per thread. Dynamic-wind is then used for the dynamic contexts within a single thread. The fluids implement the per-thread storage without having to rely thread switching points. > Do fluids have an optimized mechanism like the one I described above > for Emacs buffer-local variables? Or does each access to a fluid look > up the binding for the current thread? The latter. Each thread has a vector and a fluid is implemented as an index into that vector. Accessing a fluid consists of finding the current thread, finding the vector of that thread and indexing it. (Indices that are outside the vector yield #f on read and enlarge the vector on write.)