Re: Dynamic loading progress

[Stefan Monnier <monnier@iro.umontreal.ca>]

> I've implemented signal()

What means "implemented signal()"?  You mean, you export Fsignal to
the modules?

> Except for signal() all error related functions are unimplemented
> (they are not useful because funcall() doesn't return to module code
> on error right now).

I'm not sure what that means.  What other error-related functions?
How does this relate to whether or not "funcall() returns to module code
on error right now"?  What means "returns to module code"?

Do you provide "cdr"?  If so, what does it do when a module calls it on
a string object?  I'd expect it to signal the error and longjmp to the
nearest condition-case that catches it (presumably from outside of the
module code, unless the module code setup condition_case as well).

> * pick a new syntax and teach make-docfile how to parse it. This is
> the clean approach IMO, but it requires more work. We can use a
> sufficiently simple syntax so that it can be embedded in comments in
> other languages than C.
> * define DEFVAR/DEFUN macro in module API header file to a noop so
> that make-docfile can parse it as it is.

You're talking about how to get docstrings from the source code, but
I think we should expect Emacs to need/fetch them during "load" at which
point we'll be looking at the compiled code.  So the first question is
where should those docstrings (regardless of whether they were found and
prepared by make-docfile or by some new tool) be located?  Inside the
.so file?  Is the source code which should be placed nearby?  In some
kind of separate DOC file?

> Or we can have a full "method table" with printer function and other
> things we might need in the future. Although It's a bit overkill with
> just finalizer/printer...

Even without a printer function, I think it makes sense at least to
provide some kind of "type" information so that it's obvious when two
"user objects" are "of the same type".  The method table can play the
role of a "type".

Also, it might make sense to let Emacs build this "method table" object.
So instead of exposing an emacs_user_ptr_ops structure, export
a function which creates a pointer to such an object.  This way the
actual emacs_user_ptr_ops structure can more easily evolve, and Emacs
can more easily fill the various slots with default values where
applicable (e.g. one slot might point to the module that owns the object
and might better be filled by the Emacs core than by the module itself).


        Stefan