Daniel Colascione <dancol@dancol.org> schrieb am Mo., 28. Sep. 2015 um
21:29 Uhr:

> On 09/28/2015 08:25 AM, Philipp Stephani wrote:
> >
> >
> > Stefan Monnier <monnier@iro.umontreal.ca
> > <mailto:monnier@iro.umontreal.ca>> schrieb am Di., 15. Sep. 2015 um
> > 02:55 Uhr:
> >
> >     Just, FWIW we can keep talking about it, but my opinion is quite
> firmly
> >     made.  I want the first API to provide access to the "naked"
> primitives
> >     with no condition-case wrapping.
> >
> >
> > This is wrong and dangerous. It makes dynamic loading far less useful
> > than it could be. Essentially modules e.g. written in C++ will have to
> > consist of a small C shim that makes IPC calls to some out-of-process
> > server.
>
> While I agree that making non-local exits part of the public API is a
> titanic footgun and a mistake we'll regret for decades, it's not the
> case that it forces non-C modules to use IPC shims. Emacs non-local
> unwinding stops at the first matching condition_case on the stack, so as
> long there's a condition-case frame between a stack frame that can't be
> unwound with longjmp (say, one with C++ destructors) and the Emacs core,
> the program will work correctly if Emacs longjmps.
>

The issue is that it's impossible for module authors to write such a
`condition-case' in the general case. While individual signals can be
caught, it's not possible to catch all signals using the condition-case
Lisp function. Similarly, there is no way to write a `catch' block that
would catch all tags; `catch' only allows catching individual tag symbols.


>
> Non-local returns are awful, yes, but they do not make it impossible to
> integrate non-C languages with Emacs.
>
>