From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel Colascione Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Mon, 14 Sep 2015 11:05:02 -0700 Message-ID: <55F70C4E.8030805@dancol.org> References: <87si7977rs.fsf@tromey.com> <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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6QHbpu8swi1Hp6gkvhdlui2F5gfN9b5EV" X-Trace: ger.gmane.org 1442253981 19214 80.91.229.3 (14 Sep 2015 18:06:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Sep 2015 18:06:21 +0000 (UTC) Cc: Paul Eggert , Emacs development discussions , Philipp Stephani , =?UTF-8?Q?Aur=c3=a9lien_Aptel?= , Tom Tromey , Stephen Leake To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Sep 14 20:06:12 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 1ZbY8l-0001Rl-Ak for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 20:06:07 +0200 Original-Received: from localhost ([::1]:42665 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbY8k-0002u5-Io for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 14:06:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43307) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbY82-0002nH-04 for emacs-devel@gnu.org; Mon, 14 Sep 2015 14:05:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbY7y-0004F9-1X for emacs-devel@gnu.org; Mon, 14 Sep 2015 14:05:21 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:36542) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbY7x-0004El-Ej for emacs-devel@gnu.org; Mon, 14 Sep 2015 14:05:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From:Cc:References:To:Subject; bh=++mwG1NroCDCLTXG522QM/a94nVYRC4CbOwsZRb5G2U=; b=LrhcAEFBO2/mykGWKS4hgUCvVVhqQBhae1qDbvsTZV0PpK0iz3p6U07uEVYrDDCzXOwPZ37tlRqk4CPkI4G9xTf80wtlJRIypX0Zeuqazj9DZ2uJdRw7jIg4KTaAM67NeoY9VLNUghlH61DkfGZUKnRASLqeW3x1J5ivXBQ9dc/Fw0vEJFBo65sigyb/tVbe+kFhFcGQ49bVoDZchPiINv3o3pBOUWlEZCYc7pSZjPQjakhvHh3y4/bY8TFXOqN1JdUejNYiGKSXvsq81izCHHp1STEd/3twdwq1IVNVr9OhflC9DN/i3/EY6A5CECEUruT7LKbhyGZaPpLHzLzWTg==; Original-Received: from c-24-16-208-239.hsd1.wa.comcast.net ([24.16.208.239] helo=[192.168.1.210]) by dancol.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84) (envelope-from ) id 1ZbY7n-0001oy-13; Mon, 14 Sep 2015 11:05:07 -0700 X-Enigmail-Draft-Status: N1110 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:189953 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6QHbpu8swi1Hp6gkvhdlui2F5gfN9b5EV Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 09/14/2015 10:48 AM, Stefan Monnier wrote: >> Representing errors more conventionally is cheap. >=20 > 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, >=20 > 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. >=20 > 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. >=20 > 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. >=20 >>> 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 nee= d >>> to be protected somehow from non-local exits. >> Calls back to Emacs functions will be fairly common, because modules u= se >> these functions to manipulate Emacs data on behalf of their own caller= s. >> Any of these functions can quit. What you're imagining will be a rare >> case will in fact be common. >=20 > 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 peop= le? >> I also don't think it's correct that the Emacs-specific module code wi= ll >> work properly in the presence of modules. You're supposing too much >> patience and knowledge on the part of third-party module authors who'l= l >> want to provide bindings not only for Emacs, but for other systems as = well. >=20 > I don't forsee droves of coders who no nothing about Emacs internals an= d > 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. >=20 > 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. >=20 > You're nitpicking. Of course we'd use something slighly different whic= h > 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. >=20 >> Errors from module-invoked functions to propagate normally from the >> perspective of surrounding Lisp code. >=20 > [ 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". --6QHbpu8swi1Hp6gkvhdlui2F5gfN9b5EV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBCAAGBQJV9wxPAAoJEN4WImmbpWBl1qoP/i/xz6+ufzuUVi1g13x676AY WG1fuaC3rrDGhYrRmKalqIViMza+zMcw98ua0qMe/Fzvz+Q0mym+Ao5O4++4bGAM vhA/DrdojZK4srwFrteg2J/J5NMsRcp8NrTn/wBrCTnUH+DMqo5azquj2BwlwBlT 8GOmNdDK6fWRL/frEb3eBUNhkkcz4zmH8YQAQiN1x388dh1I2RZ/zwUtEsro+fVb l3DxQ0P/+sAcHvcP+NLwFKB+NbikckHYbFM25vnks/GU6eSCNT1JwWIQOfIJnjf8 bUwjgzqMuPVLKBkxVvU1ucCsl8O2SPyS0gEdKLSQBYhjMK5MeZzFyIg1672fD52D +umQbet13ppIIGOWFPUQFYjSLz7de4UGumKWHazEAO6+Q95Vt3K3g+Qt/UsWKZfo qa/t0yqCyFnrHWYrPl6ZTx/hlulzlt3i4u4qQzR65Efk2RRs/PiG8QNuMg8hSnzG jJHL62gGYxkEGQ0tAWUz3Fxl2AcZDA++sU0y6UzCwEgNISyBIYW0StcT8b2rRFf0 IBltEnW7N9j3CX3TC6k7BRfJPPmKG/5Oqkwmw+/5OoAMk3FEtEeA7j4OA97KgHtO QrGRWjleonNY9ZgKbFh27TZAW/Ad35vGAmdQcQ76Vg9Bi8DAIGQFLP7GQ5McCAFO yyBYJErmtGN/T+pb75oh =uVLG -----END PGP SIGNATURE----- --6QHbpu8swi1Hp6gkvhdlui2F5gfN9b5EV--