Re: Dynamic loading progress

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > It looks like modules need:
 > 
 >  . A function to replace the DEFUN macro and the related defsubr call.

Aha, so you already figured this out for yourself.

 >  . Some definition of Lisp_Object
 > 
 >    This already presents at least 2 problems.  The first is 32- vs
 >    64-bit issues.  We need some way of checking that a 32-bit module
 >    isn't loaded by a 64-bit Emacs, and vice versa.
 > 
 >    The other problem is more serious: Emacs can be built with or
 >    without --check-lisp-object-type, and with or without --wide-int;
 >    how will the module know which implementation to use?

XEmacs builds a separate compiler driver ellcc that knows how to build
modules of the same configuration.

 >    Perhaps the solution is to make Lisp_Object an opaque data type for
 >    the modules, and not use the definition we have on lisp.h.

I don't know how you identify type of objects, but since you only have
a couple of tag bits left, I have to assume you use a header word of
some kind.  In XEmacs the header word is a pointer to a table of
functions that define the common functionality of Lisp objects used by
the interpreter and the virtual machines.  Whether a method table
pointer or an enum, that header word is pretty much the only thing
that's going to be common to all types.  Seems to me that's pretty
close to opaque already.

 >  . Functions to access values of Lisp objects.

Not values, attributes.  You don't want to just unbox the Lisp object
and give modules access to internals.  Rather, each object type should
export a specific API in the form of accessors and mutators for its
Lisp-visible attributes.

This is what XEmacs already does, it's what Python does, and it's
those two examples that give me the confidence that it will work for
Emacs too.  Sounds like it will be a pile of work, but you don't have
to convert all types immediately.

 >  . Functions to create Lisp objects and/or set their values.  Again,
 >    we shouldn't rely on the likes of XSETCONS.  There should be a
 >    function make_FOO for each object type FOO.  This includes creating
 >    symbols, so 'intern' should not be needed by modules.

`intern' *is* the creation function for symbols.  Uninterned symbols
are hardly useful for modules; they already have a private namespace.

 >  . A function to create a Lisp object that is a container for a C
 >    struct or pointer.
 > 
 > The above means that most of the C source files under modules/ should
 > be thoroughly rewritten.

Sounds like a good idea to me.  Wouldn't hurt if you rewrote most of
the C source under src/ that way too. ;-)