Stefan Monnier <monnier@iro.umontreal.ca> schrieb am Mi., 30. Sep. 2015 um
10:52 Uhr:

> BTW, all this discussion about C++ modules seems to miss the point:
> Emacs's own API will be a C API.  When you want to use it from a C++
> module, you'll have to convert it to a C++ API.


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).


>   At that point, you
> have various options:
>
> - 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).


> - do an "idiot-proof" binding which only provides a "safe_funcall" which
>   catches longjmps and turns them into local exits.
>

This is what Daniel and I prefer, however I'd like to avoid the negative
spin of the word "idiot" here. To use the first option, a module author has
to know all of the following:
- that Emacs uses longjmp for non-local exits in Lisp (currently an
implementation detail_;
- that longjmp is in general unsafe in C++ code;
- which subset exactly of C++ is safe for longjmp;
- how to correctly set up the necessary traps to reliably catch all
longjmps.
I think it's a stretch to call everyone who doesn't know all of these
things an "idiot". Implementing this option is relatively straightforward;
implementing the first option makes it much harder for module authors, with
negligible benefit to the Emacs core.


> - do an "idiot-resistant" binding which only provides a "safe_funcall" that
>   catches longjmps and turns them into C++ exceptions, and then back
>   into Elisp longjmps (and back-and-forth ad nauseum if needed when
>   doing nested mutual callbacks).
>

No, this is what a C++ binding to the module interface would have to
provide.


> I'm fine with any of those things, and AFAIK they can all be done on top
> of the plain C API with the usual non-local exits.
> All I care about at this point is the plain C API.
>
>
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.