Re: Dynamic loading progress

[Stefan Monnier]

> True, and I think nobody expects otherwise. However, as with other
> interfaces, the Emacs module interface should use not all of C, but the
> intersection of C and C++ (which is pretty large compared to full C).

That would be desirable, but less so than the fact that the API just
exposes the functionality provided by Emacs's core code.
So as long as Emacs's signaling facility uses longjmp, that's going to
be exposed in the core API.

>> - do a minimalist binding which keeps using naked longjmp, and just
>> let the C++ code use explicit internal_condition_case wrappers where
>> it thinks it's needed.
> This is currently impossible because the necessary code is not available to
> module authors (and partially does not even exist, as in the case of catch).

Irrelevant detail: we're talking about design of some upcoming API,
which will require coding.  Some of that coding may involve writing new
core code, of course.

Of course, by that measure, some of that coding could involve replacing
longjmp with some other mechanism.  My gut feeling is that this would be
a very large undertaking and that the result would probably not be
palatable to the vast majority of Emacs's C contributors, so I won't
hold my breath.

> Daniel has designed a great API in
> https://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00960.html.  Let's
> just implement this API as designed and check later if there's any need for
> the other options.

If you want:

    Modules can call Lisp functions using `funcall', which does the
    obvious thing.  If Lisp signals or throws, `funcall' returns NULL.

that's OK, but it should then be called `safe_funcall', and we should
provide another `funcall' which does not catch the error.

And if `safe_funcall' cannot be defined "by hand" in a module using
other API methods, that would mean that the API is still lacking
functionality (e.e. lacking condition_case and things like that).

You're not going to convince me otherwise.


        Stefan