Re: Dynamic loading progress

["Stephen J. Turnbull" <stephen@xemacs.org>]

Eli Zaretskii writes:

 > > I don't understand.  XEmacs's ELLs (dynamically loadable modules)
 > > have no problem with calling Lisp (use Ffuncall) or using symbols
 > > (use Fintern).  The only requirement that I've seen expressed in
 > > this thread that XEmacs ELLs don't satisfy is that a module
 > > should be compilable for use with multiple versions of XEmacs
 > 
 > This last requirement is what is being discussed here.  The capability
 > of creating Lisp objects depends on the internals, and AFAIU we would
 > like to avoid having that dependency.

It's not very hard to get backward compatibility (old compiled modules
work in new Emacs).  Define a stable ABI, and then stick to it.

It shouldn't be that hard to do it.  Most Lisp functionality of most
types is accessed through the object header, which points to a class
descriptor, which is basically a table of methods.  In XEmacs there's
a constructor, a finalizer (optional), a printer, a gc-marker
(optional), and a couple of others I forget offhand.  Add a length
indicator at the beginning, never change the order of methods from
past versions, and I think you're done.  If you add new methods in new
Emacs, no problem, just add them at the end of the table.  If you
deprecate old ones, just leave the slots and insert an unimplemented
marker (probably (slot_fun *) NULL will do but you could get fancy and
have a slot_deprecated_fun to put in that slot).  Sure, unneeded slots
may accumulate over time, but you're going to have only a few dozen
types at most and a couple unused slots per type.

Then require that module functions access other modules (including
core) only through Lisp (ie, Ffuncall and Fintern), which has a very
stylized calling convention.  If you find more efficiency is needed by
some modules, you can expand the allowed functions in new Emacs.

 > I wasn't talking about using Lisp by modules, I was talking
 > specifically about calling Lisp from C.  Implementing new
 > primitives for performance purposes doesn't need that, at least it
 > isn't clear to me why it would.

I just don't see what the problem is.  We call Lisp from C all the
time, that's what Ffuncall *is*.  It appears in most backtraces. :-)
I don't know about Emacs conventions back when you had GCPROs, but in
XEmacs you see functions marked "can GC" all over the place, precisely
because they call Lisp.

In the above, I'm being a little facetious, but it seems to me that
calling Lisp from C is much safer and more straightforward than
calling C from C.  Up to GCPRO, but Emacs doesn't have that any more,
correct?