Re: Dynamic loading progress

[Aurélien Aptel]

Your approach is interesting but it currently works as-is for 64bits
platforms and 32bits platform without wide-int and can be fixed later
without breaking the API, if I understand correctly.

I would rather focus on the remaining blocking things for the merge in
master (and availability in Emacs 25!):

* New opaque Lisp type to embbed C pointers with a vtable (for at
least a finalizer)

Can we re-use the finalizer feature you implemented? I haven't looked into it.

* Loading

I'm currently in the process of having `load' look for modules. For
this I've added the system shared lib extension (.dll, .so, ...) to
Vload_prefixes choosen at configure time (modules are not handled in
Fload at the moment).
I know that on OSX there's both ".dyn" and ".so" but I don't know much
about it. Is supporting both worth it?

Couldn't we simply pick an extension like ".edm" (emacs dynamic
module) and rename the generated lib on each system when a module is
built?

* Doc strings

If we use the doxygen syntax, it won't follow the various elisp
conventions (args in caps, first line must be descriptive, etc).
Jumping to definition is also pretty convenient, should we keep that
feature for modules? Also how should we load the docstrings
themselves?

* Packaging

We need to extend the spec of ELisp packages to take into account
modules. The way I see it a module will have a "core" source file in C
(or something else) and a bunch of helpers implemented in elisp on top
that expose the package features in a more user-friendly way.

As for distribution, only packaging sources is easier. This is a
pretty big undertaking but we could bundle a compiler on platforms
that don't have one easily accessible (like Strawberry Perl on Windows
that bundles mingw-w64).