Re: Smart variables, dumb variables

[Rob Browning <rlb@defaultvalue.org>]

Marius Vollmer <mvo@zagadka.ping.de> 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