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

[Ken Raeburn]

Richard Stallman <address@hidden> writes:
> I don't think this method makes real sense, because if an object is
> going to have the scheme object header at all, we may as well use that
> object header universaly throughout Emacs as the way to reference the
> object.  It would cost no extra storage, and it would be simpler.

It would certainly be simpler, just a little slower as the
object-to-pointer conversions are done multiple times, particularly
when a function called frequently is changed from taking a pointer
argument to taking a lisp object.  I've made a few changes along those
lines, and will almost certainly make more.

> Why can't Guile's symbols be used as Lisp symbols?

Actually, the issue is the symbol's value(s).  Scheme symbols don't
have separate function and value slots.  Emacs Lisp symbols have a few
other fields associated with them, like indirect_variable, that also
don't fit the basic Scheme model.  And if we separate the name from
the values, there's the question of what exactly a symbol is.

There are several ways to deal with this.

Some involve changing Guile's symbol representation to have the extra
fields.  IMNSHO this is tantamount to declaring Scheme not to be up to
the task of implementing Lisp, and I'm not prepared to believe that.
(That Guile isn't currently up to the task, maybe; we'll find out, and
Guile's Scheme implementation can be improved.  That Scheme can't do
it, no.)  It also sets a poor example for people wanting to put other
existing languages on top of Guile.

Another approach would be to use Scheme symbols, but store as their
values vectors containing the various fields of a Lisp symbol.
Special accessor functions would be needed for Scheme code to
manipulate Lisp variables, and while I don't have a problem with that,
the people who want transparent interaction between the two languages
probably won't like it.  I guess it depends whether you view it as
Lisp on top of Scheme, or the two languages working side by side.  I'm
inclined towards the former view, maybe only because it's easier for
an implementor or designer, but I understand the temptation of the
latter for such similar languages.

But in that case, how do you implement Lisp's "symbolp" when looking
at Scheme objects?  Is a Lisp symbol a Scheme symbol that has a
particular kind of object as its value?  Should other Scheme symbols
be treated as Lisp symbols?  If a Scheme symbol has a value, what
happens if you do an "fset" or "let" on it in Lisp?  (Maybe that's an
argument for separate namespaces for Scheme and Lisp symbols, outside
of explicitly requested sharing.)

Treating Lisp symbols as a new type is a third approach.  (Either an
opaque type, or a vector as above but also including the symbol's
name.)  It's what I did before, and it does sidestep a lot of these
issues by simply not allowing any sort of confusion between the two
symbol types, but it's not as appealing as using Scheme symbols.


A related issue is the symbol name -- a Lisp symbol name is a Lisp
string, with some of the associated fields ignored for matching
purposes.  The names themselves can have text properties:

    ELISP> (symbol-name 'booga-booga)
    #("booga-booga" 0 3 nil 3 6
      (some-prop some-val)
      6 11 nil)

(I got this by previously interning a string with the same contents
and some text properties.)

An Emacs Lisp symbol's name can also be changed after interning, such
that it won't be found when interning either the old name or
(probably) the new name.  I don't know what Scheme's specifications
might say about such cases.  (Much as I like Scheme, I'm hardly an
expert; on subtle Scheme issues I'll readily defer to others.)

I really hope no one is relying on such weird behavior, but if it
needs to be maintained, that's another complication.


Because I don't have all the answers, I think it's simplest to plan to
treat them as separate types initially, and then merge them if and
when we decide a particular approach will work well in all cases we
care about, perhaps even before the actual coding starts, but perhaps
not; worst case, we change a few Lisp macros to just invoke Guile
macros.  It's easier than starting coding on the assumption that
they'll be the same, and then finding that we have to separate them.

Ken