From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Re: Smart variables, dumb variables Date: Wed, 14 Aug 2002 16:31:28 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <87znvpf7pr.fsf@raven.i.defaultvalue.org> References: <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 1029360678 16667 127.0.0.1 (14 Aug 2002 21:31:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 14 Aug 2002 21:31:18 +0000 (UTC) Cc: guile-devel@gnu.org 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 17f5jV-0004KR-00 for ; Wed, 14 Aug 2002 23:31: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 17f5kN-0006X8-00; Wed, 14 Aug 2002 17:32:07 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17f5jp-0006Vb-00 for guile-devel@gnu.org; Wed, 14 Aug 2002 17:31:33 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17f5jn-0006VN-00 for guile-devel@gnu.org; Wed, 14 Aug 2002 17:31:32 -0400 Original-Received: from dsl-209-87-109-2.constant.com ([209.87.109.2] helo=defaultvalue.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17f5jm-0006VI-00 for guile-devel@gnu.org; Wed, 14 Aug 2002 17:31:31 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 625A5EF8; Wed, 14 Aug 2002 16:31:29 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 8555B2DCC; Wed, 14 Aug 2002 16:31:28 -0500 (CDT) Original-To: Marius Vollmer In-Reply-To: <87y9bajzfp.fsf@zagadka.ping.de> (Marius Vollmer's message of "13 Aug 2002 22:06:50 +0200") Original-Lines: 54 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-pc-linux-gnu) 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:1084 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:1084 Marius Vollmer writes: > 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). Hmm, my initial reaction is that this kind of "transparency" always makes me nervous. In fact I'd probably be happier if emacs made some of the operations *more* explicit. i.e. I'd rather see (set-customized-var! some-foo value) rather than have to remeber that (set! some-foo value) may be doing all kinds of fancy operations I'm not aware of, depending on a definitions that may not be visible at the scheme level. Also, sticking with functions rather than raw variables for important "globals" makes your life far less unpleasant if/when you decide you want or need to function in the presence of (preemtive) threads. However, I understand the reasoning, so I wonder whether or not we might be able to come up with a broader solution (as you alluded to) to start with. We already have goops and procedures with setters -- can we come up with something along those lines that can still be optimized (even if we can't do that optimization right now)? If so, those optimizations might help elsewhere too. Questions: how bad would the overhead for "raw variables" be if we moved in this direction, and is our current bottleneck really raw variable accesses? Overall, I guess I just have a reflexive nervousness wrt "magic variables". If nothing else, they make code that much more mysterious to anyone coming to a project/language from the outside, but all that said -- I'm already strongly opposed or anything, just wary. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel