From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Mon, 14 Sep 2015 20:55:49 -0400 Message-ID: References: <55DB7C3D.4090106@cs.ucla.edu> <55DE75FD.8020308@cs.ucla.edu> <55F5DD8C.70506@dancol.org> <55F62C16.4000105@dancol.org> <55F64F04.9030002@dancol.org> <55F6E43E.9030502@dancol.org> <55F70C4E.8030805@dancol.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1442278572 1606 80.91.229.3 (15 Sep 2015 00:56:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Sep 2015 00:56:12 +0000 (UTC) Cc: Paul Eggert , Emacs development discussions , Philipp Stephani , =?windows-1252?Q?Aur=E9lien?= Aptel , Tom Tromey , Stephen Leake To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 15 02:56:03 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZbeXR-0004yQ-Kj for ged-emacs-devel@m.gmane.org; Tue, 15 Sep 2015 02:56:01 +0200 Original-Received: from localhost ([::1]:44336 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbeXQ-0001sh-Jq for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 20:56:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37923) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbeXN-0001sY-96 for emacs-devel@gnu.org; Mon, 14 Sep 2015 20:55:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbeXI-0003TI-84 for emacs-devel@gnu.org; Mon, 14 Sep 2015 20:55:57 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:19588) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbeXI-0003Sr-0N for emacs-devel@gnu.org; Mon, 14 Sep 2015 20:55:52 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0CiDQA731xV/0jo92hbAYMQgTKCUMhgBAICgTw9EAEBAQEBAQGBCkEFg1wBAQEBAgFWIwULCw4KGQIBEhQYDSQTGYgLCM8jAQEBAQEFAgEfizqFBQcnAYQFBZ8XkhSDWSOBZoIuIjGCRwEBAQ X-IPAS-Result: A0CiDQA731xV/0jo92hbAYMQgTKCUMhgBAICgTw9EAEBAQEBAQGBCkEFg1wBAQEBAgFWIwULCw4KGQIBEhQYDSQTGYgLCM8jAQEBAQEFAgEfizqFBQcnAYQFBZ8XkhSDWSOBZoIuIjGCRwEBAQ X-IronPort-AV: E=Sophos;i="5.13,465,1427774400"; d="scan'208";a="164848730" Original-Received: from 104-247-232-72.cpe.teksavvy.com (HELO ceviche.home) ([104.247.232.72]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Sep 2015 20:55:51 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id AD2BE66113; Mon, 14 Sep 2015 20:55:49 -0400 (EDT) In-Reply-To: <55F70C4E.8030805@dancol.org> (Daniel Colascione's message of "Mon, 14 Sep 2015 11:05:02 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:189958 Archived-At: 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. Stefan >>>>> "Daniel" == Daniel Colascione writes: > On 09/14/2015 10:48 AM, Stefan Monnier wrote: >>> Representing errors more conventionally is cheap. >> >> AFAIK "representing errors more conventionally" means wrapping every >> single function we pass to the module API. That's definitely not cheap >> in terms of performance. > Yes, we need an internal condition-case at the boundary between the > module API and the Emacs core. I can call setjmp 54 million times per > second. (100000000 runs in 183ms.) Performance is simply not a problem. >>> If there's even a small chance that I'm right about the safety and >>> maintainability advantages of using purely local exits, >> >> Representing errors as exceptions also has advantages. > Besides performance? Longjmp for error handling has an _expressiveness_ > advantage in the Emacs core, but that's because we use GC data > structures for everything. Not so with external modules. >>> why not err on the side of caution? AFAICS, there's no advantage to >>> using non-local exits and plenty of risks. >> >> There are very many advantages, on the contrary. > In a non-local exit scheme intended for use with third-party code and > not supported by any standardized exception system (like C++ exceptions > or SEH), I see only risks. >> >> Also, I expect most module authors will be familiar with Emacs, and >> having to learn a different style will be an extra hindrance. > I expect them to be familiar with Emacs. There is no need to make module > developers familiarize themselves with Emacs internals. The public API > should insulate them from that. >> >>>> But the issue only comes up once these non-Emacs libraries call back to >>>> Emacs functions (i.e. step 5 in my example). So only those calls need >>>> to be protected somehow from non-local exits. >>> Calls back to Emacs functions will be fairly common, because modules use >>> these functions to manipulate Emacs data on behalf of their own callers. >>> Any of these functions can quit. What you're imagining will be a rare >>> case will in fact be common. >> >> You're not talking about the "step 5" case. You're talking about the >> Emacs-specific module code calling Emacs functions. Indeed, this will be >> very common. But to write this code, you will have to know a fair bit >> about Emacs internals, anyway. It will not look like your "typical C++ >> code". > Why shouldn't it? We _can_ make it look just like typical C++ code, and > to encourage module development, we should. Why make life harder for people? >>> I also don't think it's correct that the Emacs-specific module code will >>> work properly in the presence of modules. You're supposing too much >>> patience and knowledge on the part of third-party module authors who'll >>> want to provide bindings not only for Emacs, but for other systems as well. >> >> I don't forsee droves of coders who no nothing about Emacs internals and >> who start writing third party modules. > Plenty of developers know nothing about Java or Python or Ruby or C# or > V8 internals and write native extensions for these systems. Supporting > developers who know the Lisp side of Emacs and who don't want to be > bothered working in core is one of the most important use cases of the > module system. >> >> In any case, I think it would be easy to layer the kind of API you >> imagine on top of the kind of API I imagine, whereas the reverse seems >> to be much more difficult and/or much less efficient. > On the contrary, layering a different non-local exit scheme on top of an > error flag scheme is elegant. Imagine a C++ module library that throws a > C++ exception upon returning from Emacs and seeing the error flag set, > the translates (just before returning from C++ to Emacs) that C++ > exception back into an Emacs error. Now you have a non-local error > scheme that is exactly the right thing for both languages. >> So I'd rather we go with a straightforward lean API for a start. >> And we can develop an alternative API on top afterwards (it might even >> be possible to implement this alt-API as a module). > A local-exit-only API _is_ a lean API, at least from a semantics > perspective. It's not surprising. The cost of the error flag machinery > in terms of both performance and API specification space is minuscule as > well. >>>> Of course it is. We already do that in Emacs's core with things like >>>> safe_call. >>> safe_call blindly suppresses errors. >> >> You're nitpicking. Of course we'd use something slighly different which >> stores the error somewhere. Th point remains that it's easy to provide >> such a wrapper. > So now we need some kind of explicit error propagation machinery > *anyway*, plus we're making developers worry about non-local exits. > Let's skip the latter part. >> >>> Errors from module-invoked functions to propagate normally from the >>> perspective of surrounding Lisp code. >> >> [ Is there a verb missing, maybe, I can't quite parse this, sorry. ] > s/to // > I don't want C-g to break when module, core, and lisp frames are mingled > on stacks, and I expect these situations to be fairly common, especially > if we support modules with names like "python" and "guile".