Stefan Monnier <
address@hidden> 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.