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: 13 Aug 2002 21:13:19 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <87bs86lghc.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> <200208071424.g77EO0k03146@wijiji.santafe.edu> <200208091639.g79GdbQW003675@santafe.santafe.edu> <200208130147.g7D1lsR07028@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 1029266003 25428 127.0.0.1 (13 Aug 2002 19:13:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 13 Aug 2002 19:13:23 +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 17eh6Y-0006c1-00 for ; Tue, 13 Aug 2002 21:13:22 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17ehVC-0004oO-00 for ; Tue, 13 Aug 2002 21:38:50 +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 17eh7O-0006oe-00; Tue, 13 Aug 2002 15:14:14 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17eh6V-0006n7-00 for emacs-devel@gnu.org; Tue, 13 Aug 2002 15:13:19 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17eh6T-0006mc-00 for emacs-devel@gnu.org; Tue, 13 Aug 2002 15:13:18 -0400 Original-Received: from dialin.speedway42.dip154.dokom.de ([195.138.42.154] helo=zagadka.ping.de) by monty-python.gnu.org with smtp (Exim 4.10) id 17eh6S-0006mE-00 for emacs-devel@gnu.org; Tue, 13 Aug 2002 15:13:17 -0400 Original-Received: (qmail 3608 invoked by uid 1000); 13 Aug 2002 19:13:19 -0000 Original-To: rms@gnu.org In-Reply-To: <200208130147.g7D1lsR07028@wijiji.santafe.edu> Original-Lines: 50 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:6503 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:6503 Richard Stallman writes: > > But I think that running arbitrary code is not good > > design--variables should be variables, not act like functions. > > But they could be used as the basis for all kind of funny > variable-like behavior. > > It could be. I wonder if there is a way to implement this that > discourages misuse of the feature. If we would implement this, we could first make it only available to C. I expect people to want to use it from Scheme immediately, and yell at us for not giving it to them. We could then answer that there are better ways to achieve the same thing, like settable functions. > Perhaps, instead of providing a way to say "run this code when there > is an access to variable FOO", it could have to be done in two steps: > first, define a feature for something special to do when accessing > certain variables; second, turn on one of these features for a certain > variable. Yes. I don't understand what you are proposing in detail, but I'm thinking about adding flags to our existing variables: one would be for read-only variables, one would be for 'dumb' variables that you are allowed to access directly (which I think is important for performance), and maybe others. When a variable is not dumb, you need to call scm_variable_ref, etc to access it, and these functions would then be the single place where new behavior can be added. If you don't care about performance too much, you can just use scm_variable_ref, etc without looking at the flags. Otherwise, the flags tell you what shortcuts you are allowed to take. The feature for doing something special would be implemented inside scm_variabe_ref, etc. To activate it, you would need to construct a variable with the right flags. You wouldn't be able to change the flags of existing variables. > Of course, it is possible to write a higher level feature that would > package up and combine those two steps. It would not be difficult. > But many people would get the point and realize that was the wrong > thing to do. Yes, the variables that can run code on access need to be specially constructed. You wont be able to specify code to be run for an arbitrary variable. Sorry if I wasn't clear about this. -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405