[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Dynamic loading progress

From: Philipp Stephani
Subject: Re: Dynamic loading progress
Date: Mon, 28 Sep 2015 20:09:49 +0000

Daniel Colascione <address@hidden> schrieb am Mo., 28. Sep. 2015 um 21:29 Uhr:
On 09/28/2015 08:25 AM, Philipp Stephani wrote:
> Stefan Monnier <address@hidden
> <mailto:address@hidden>> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]