Aurélien Aptel <
address@hidden> schrieb am Do., 15. Okt. 2015 um 01:32 Uhr:
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 be more worried about representation of nullptr. With casting nullptr can stand for a valid Lisp value, so that it's not possible to return invalid values, which is visible to the user.
* Loading
I know that on OSX there's both ".dyn" and ".so" but I don't know much
about it. Is supporting both worth it?
According to
http://stackoverflow.com/a/2339910/178761 there are two types: bundles and dynamic libraries. The differences were bigger in the past (only bundles could be loaded dynamically), but now they are mostly equivalent. Apparently .so and .bundle are usually used for bundles and .dylib for dynamic libraries, but e.g. your example modules compile as dynamic libraries with an .so extension and Emacs is totally happy. So supporting .so should be enough.
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?
I'd prefer using the conventional extensions. A custom extension might confuse users and clash with existing meanings of that extension.
* 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?
Can't modules already run the equivalent of
(put 'module-func 'function-documentation "docstring")
? With that the basics should already be there.
* 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.
That is one option, but modules consisting entirely of non-Elisp files are also to be expected, given that the module API is as powerful as Elisp.