From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.devel Subject: Smart variables, dumb variables Date: 13 Aug 2002 22:06:50 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <87y9bajzfp.fsf@zagadka.ping.de> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1029269175 3269 127.0.0.1 (13 Aug 2002 20:06:15 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 13 Aug 2002 20:06:15 +0000 (UTC) Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17ehvh-0000qa-00 for ; Tue, 13 Aug 2002 22:06:13 +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 17ehwY-00045x-00; Tue, 13 Aug 2002 16:07:06 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17ehwH-000442-00 for guile-devel@gnu.org; Tue, 13 Aug 2002 16:06:49 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17ehwF-00043f-00 for guile-devel@gnu.org; Tue, 13 Aug 2002 16:06:48 -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 17ehwF-00043a-00 for guile-devel@gnu.org; Tue, 13 Aug 2002 16:06:47 -0400 Original-Received: (qmail 3629 invoked by uid 1000); 13 Aug 2002 20:06:50 -0000 Original-To: guile-devel@gnu.org Original-Lines: 60 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:1071 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1071 Hi, currently, our global variables are strictly passive containers. Accessing a variable is just a memory reference. I think we need to keep this for performance reasons. However, we might also want to have more fancy variables. One might want to get a notification when a variable is set, or one might want to fetch the real value from some indirect location. For example, Emacs has the ability to forward references to Elisp variables to C variables. C code can use a normal "int" variable, say, and Elisp code can use that variable as well. Translating between Elisp representation and C representation of values is done transparently, when Elisp accesses the variable. RMS convinced me that that would be a nice feature for Guile as well, in general. One might say that it is probably better to not use variables for this, but rather have a more abstract interface using setter and getter functions. But when designed carefully. the need to use stters/getters for things that are in all respects just variables can also feel awkward. A good example are the forwarding variables of Emacs. It shouldn't really be visible to Elisp code that the variables are forwarded to C variables (although they don't allow non-integer values, thus making them different from other Elisp variables, hmm). I'd like to propose a slight modification to our variables that would allow us to cleanly mess with what variables exactly are in the future. I would add a 'flags' field to variable smob (there is room for it), with the following flags defined initially: - SCM_F_VARIABLE_DUMB When set, the variable is 'dumb' and can be referened and set with SCM_DUMB_VARIABLE_REF and SCM_DUMB_VARIABLE_SET, respectively. When it is not set, you need to call scm_variable_ref and scm_variable_set_x. - SCM_F_VARIABLE_READONLY When set, the variable can not be set. You are not allowed to use SCM_DUMB_VARIABLE_SET and scm_variable_set_x will result in an error. A future execution model (that is slowly forming in my head) will make it so that most variable flags can be tested at compile time. Thus, a compiler can emit more efficient code for dumb variables. One possible next step would be to somehow involve Goops in this and turn scm_variable_ref into a generic function, the way scm_sum is already. Opinions? -- GPG: D5D4E405 - 2F9B BCCC 8527 692A 04E3 331E FAF8 226A D5D4 E405 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel