From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Dynamic modules: emacs-module.c and signaling errors Date: Fri, 27 Nov 2015 10:26:37 +0200 Message-ID: <838u5ju9tu.fsf@gnu.org> References: <83k2p7xk13.fsf@gnu.org> <87wpt7p369.fsf@tromey.com> <83d1uzxgvw.fsf@gnu.org> <5654D7CF.90001@cs.ucla.edu> <87si3vox7j.fsf@tromey.com> <56555B52.3030703@cs.ucla.edu> <837fl6xa02.fsf@gnu.org> <5655F10D.9080805@cs.ucla.edu> <83vb8ovkc5.fsf@gnu.org> <83a8q0vgb9.fsf@gnu.org> <83si3stuzn.fsf@gnu.org> <83poywtsxl.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1448612841 10695 80.91.229.3 (27 Nov 2015 08:27:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 27 Nov 2015 08:27:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 27 09:27:10 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 1a2EMu-0007vA-6C for ged-emacs-devel@m.gmane.org; Fri, 27 Nov 2015 09:27:00 +0100 Original-Received: from localhost ([::1]:55305 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2EMw-0004Eh-It for ged-emacs-devel@m.gmane.org; Fri, 27 Nov 2015 03:27:02 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51817) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2EMs-0004ER-9F for emacs-devel@gnu.org; Fri, 27 Nov 2015 03:26:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1a2EMn-0000LR-7W for emacs-devel@gnu.org; Fri, 27 Nov 2015 03:26:58 -0500 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:56733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1a2EMm-0000KS-V4 for emacs-devel@gnu.org; Fri, 27 Nov 2015 03:26:53 -0500 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NYG00G00SEYM000@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Fri, 27 Nov 2015 10:26:51 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NYG00GQPSSQIQ90@a-mtaout21.012.net.il>; Fri, 27 Nov 2015 10:26:51 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 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:195353 Archived-At: > From: Stefan Monnier > Cc: emacs-devel@gnu.org > Date: Thu, 26 Nov 2015 20:21:26 -0500 > > >> >> Because this loses the connection between the signal and its origin. > >> > Not really, it doesn't. You get the same Lisp error you'd get in > >> > Emacs proper. > >> That's only the signal, not its origin. Its origin is lost. > > Not sure what you mean by that. The origin is clearly stated in the > > error message. > > You mean debug-on-error will properly show me the right stack state and > let me look up and change the corresponding variables? Up to the C level, yes. You cannot do that once you get to the C level, not with the Lisp debugger we have. > Hmm... didn't think so. Can you show some example of where some data is lost? Because I think we may be miscommunicating: I don't see that significant lost of data that causes such strenuous objections. Maybe you can explain that to me. Maybe something is indeed missing. > >> >> Because it imposes a cost which we may not want to pay. > >> > What cost is that? > >> Catch and then rethrow. Which is pure cost with no benefit, if you ask me. > > A cost very close to zero. > > Who cares. Still pure cost with no benefit. It's not without benefits. > The core provides naturally a plain raw non-catching funcall, but with > the current design a module author who wants this behavior can't have it Why would a module author want a non-catching funcall? Are the reasons for having that strong enough to override the dangers? Because there are other things a module author currently cannot do, as the API offers only limited ways into Emacs. Why would having a non-catching funcall be so much more important than, say, being able to add watchers to the Emacs event queue? > This is completely dumb. I'd appreciate if you refrained from name-calling. It doesn't help keep the discussion technical and constructive. > > No one needs to do anything, the code is already written, and module > > authors don't even need to know it exists, or what exactly does it do. > > The criteria to accept bad design shouldn't be "does the code > already exist?". And whether it works, yes. This is Free Software: whoever does the job gets to choose the tools and the methods. You know that. > > It's not obvious to me, sorry. The costs of the current code are > > minimal, and the advantages to have the "raw" functionality in > > addition to what we have aren't clear-cut. > > As I said, we have plenty of experience in Emacs's own source code: > look in Emacs's source code and compare the number of uses of > "safe_call" and friends to the number of uses of "callN" and friends. > The catching version is useful at times, but it's the exception rather > than the rule. XEmacs's experience is the same, apparently. Modules aren't core Emacs, and weren't supposed to be it. Not everything that's possible in core _must_ be available to modules. Modules aren't a way to extend Emacs in unlimited ways. So just saying this is possible in core is not a useful argument in this discussion. The important question here is: why is it important that modules have this functionality at their disposal.