Smart variables, dumb variables

[Marius Vollmer <mvo@zagadka.ping.de>]

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