Re: Dynamic loading progress

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 13 Feb 2015 14:11:33 -0500
> Cc: Paul Eggert <eggert@cs.ucla.edu>, emacs-devel@gnu.org
> 
> > I would start by coming up with the minimum set of requirements a
> > module needs to be able to communicate with Emacs.
> 
> Easy: take the existing sample modules and see what they need.

No one seems to care, so I will bite the bullet.  The below is based
on looking at the modules branch.

It looks like modules need:

 . A function to replace the DEFUN macro and the related defsubr call.

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

   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.

 . Functions to access values of Lisp objects.  We shouldn't rely on C
   macros like XINT and XWINDOW for that, because macros track too
   closely the internals of each object.  So I propose to use
   functions that will be exposed via the API.

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

 . 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.  They are currently written as if the code
were an integral part of Emacs on one of the Emacs C files.  Going
that way means that modules will have to be recompiled from sources
for each Emacs version, and practically will have to live in the Emacs
tree.  Maybe this is what we want, I don't know.