Re: emacs and guile (Re: ehelp woes, or why I hate a module that I love so much)

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

Richard Stallman <rms@gnu.org> writes:

>     Some involve changing Guile's symbol representation to have the extra
>     fields.
> 
> If that gives good and clean results, we should use that method, for
> efficiency's sake.

We already have two extra fields on symbols, one for a function and
one for a plist.  Access to these slots is very fast since they are in
symbol header itself.

For additional fields, there is 'make-object-property'.  This function
returns a procedure-with-setter so that can you do, for example,

    (define symbol-foo (make-object-property))

    (symbol-foo 'x)
    => #f
    (set! (symbol-foo 'x) 123)
    (symbol-foo 'x)
    => 123

make-object-property is implemented with a hash table of alists.  If
that is too slow, we could try to speed it up.  For example, the
getter of a property might secretly use the plist of a symbol instead
of the hash table.


But note that in Guile, a symbol does not really have a value.
Symbols are used to name variables relative to some module, and these
variables have values.  We could extend this by having more than one
symbol->variable mapping per module.  For Elisp, there could be two:
one for 'variable values' and one for 'function values'.  We could
then add some primitive syntax to Guile to select a particular
mapping, for example

    Elisp: (foo foo)

could be translated into

    Guile: ((#:func foo) foo)

The form (#:func foo) would use the function mapping when looking up
the variable for foo, while the argument position will use the default
mapping.

The lookup will be done when the code is executed for the first time
(or when it is loaded, should we have a compiler) and subsequent
executions will use the variable directly.

This scheme would allow us to have function values that are also
subject to the module system, just like the normal variable values.

(I have not thought about how well this all fits with dynamic scoping,
tho...)

You might also want to talk to Neil Jerram <neil@ossau.uklinux.net>,
his work on Elisp support has progressed quite far already.