Re: emacs-dynamic-module in Emacs Git?

["Aurélien Aptel" <aurelien.aptel+emacs@gmail.com>]

Stefan's 3 part plan is sound.

I agree that using any Emacs function in modules is too fragile and we
need to define a subset or a new layer to expose Emacs features to
modules.

On Mon, Dec 1, 2014 at 4:36 PM, Ted Zlatanov <tzz@lifelogs.com> wrote:
> On Mon, 01 Dec 2014 10:04:34 -0500 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote:
>
> SM> By "API" I meant something like a .h file which modules can include to
> SM> define the functions and datatypes that they can use.  I.e. by API
> SM> I mean those things that the module code can do, rather than the things
> SM> that Emacs code can do with modules.
>
> By API I meant both directions, the module API for registration and
> metadata, and the Emacs API that modules can use. So I still think a
> call-only API (only in the direction of calling the module) is best for
> now, so that .h file is unnecessary.

In order to do anything useful (even in a "call-only" API) you need
access to Emacs facilities. At the very least access to Elisp data
structures (symbols, numbers, strings and buffers). The point of
compiled modules is also efficiency so the access has to be low level
enough (no big conversion or copying needed).

> I agree with the rest of your comments, except that it's not clear when
> you'll feel that the module loading is settled enough to merge into the
> master branch.  I think the module metadata should be formalized, at
> least, so it can be obtained before loading the module.  Aurélien, is
> that possible?  And do you have any comments?

Apart from the the new module/opaque type I'd like to add, the way I
see it the branch can already be merged and used as a very
experimental new feature. Writing the yaml module was a good exercise.
We need people to try writing modules and see what they end up
using/needing in order to choose what we should keep in the API.

For me a module package will be composed of a metadata file, a bunch
of C files implementing small and simple primitives and a bunch of
elisp files for the logic.