Re: Dynamic loading progress

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <address@hidden>
> Cc: address@hidden,
>     address@hidden
> Date: Sun, 15 Feb 2015 01:48:50 +0900
> 
> 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.

I simply don't believe this goal to be practically achievable, if
there are no limitations on the interface.

I also am not sure that people would accept forward incompatibility
easily: consider the number of people who use bleeding-edge Org, Gnus,
etc. with the last official release of Emacs.  Why would they agree to
lose that when part of a module is in C?

> 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.

Emacs objects aren't built that way, so part of what you say is
inapplicable.  But the real problems don't happen at that level, they
are elsewhere, see below.

> Then require that module functions access other modules (including
> core) only through Lisp (ie, Ffuncall and Fintern), which has a very
> stylized calling convention.

And what about accessing Lisp objects?  Most of them are accessed
through C macros, whose definitions change as the internals change.
What can you do with those to preserve compatibility across Emacs
versions?

>  > 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. :-)

It appears in most backtraces because the Lisp interpreter calls it
when it sees funcall in Lisp.

More to the point: I simply don't see any reason for calling Lisp from
C.  If a module needs to do something in Lisp, let it do it in Lisp
directly, as every external package for Emacs does.  C code should be
reserved for providing additional primitives that core Emacs lacks,
and that's all.  At least that should be the starting point, IMO.