From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Dynamic loading progress Date: Tue, 15 Sep 2015 10:46:42 +0900 Message-ID: <874miwzc71.fsf@uwakimon.sk.tsukuba.ac.jp> References: <878u97nyjn.fsf@lifelogs.com> <86d1yirnqw.fsf@stephe-leake.org> <87si7977rs.fsf@tromey.com> <55DB7C3D.4090106@cs.ucla.edu> <55DE75FD.8020308@cs.ucla.edu> <55F5DD8C.70506@dancol.org> <87fv2hzmw3.fsf@uwakimon.sk.tsukuba.ac.jp> <55F644F2.9040303@dancol.org> <87a8spzcit.fsf@uwakimon.sk.tsukuba.ac.jp> <86zj0p3vqi.fsf@stephe-leake.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1442281627 11120 80.91.229.3 (15 Sep 2015 01:47:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Sep 2015 01:47:07 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stephen Leake Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 15 03:46:58 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 1ZbfKh-0000pu-Lh for ged-emacs-devel@m.gmane.org; Tue, 15 Sep 2015 03:46:55 +0200 Original-Received: from localhost ([::1]:44465 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbfKg-0003bP-MA for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 21:46:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52795) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbfKc-0003bG-Sc for emacs-devel@gnu.org; Mon, 14 Sep 2015 21:46:51 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbfKX-0002Jq-Oq for emacs-devel@gnu.org; Mon, 14 Sep 2015 21:46:50 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:41432) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbfKX-0002HB-Eq for emacs-devel@gnu.org; Mon, 14 Sep 2015 21:46:45 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 5F0411C3904; Tue, 15 Sep 2015 10:46:42 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 33F5811EF83; Tue, 15 Sep 2015 10:46:42 +0900 (JST) In-Reply-To: <86zj0p3vqi.fsf@stephe-leake.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" ffb5abc8dc4e XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 130.158.97.161 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:189961 Archived-At: Stephen Leake writes: > > Er, because it *is* Emacs code? > > That was my initial view as well, because I new I needed fast > performance for my particular use case. > > But I suspect some (most?) modules will be added just to provide a lisp > interface to some external library; the authors will see that as part of > their lisp code, not part of Emacs core. Which is what I described and you called "conventional". But that's *not* what Daniel is exercised about. > One reason Emacs succeeds is because lisp is so forgiving; module > developers will expect the Emacs module API to be similarly > forgiving. Yeah, and they expect a pony too. The module API will be C, which is not a forgiving language. Lisp forgiveness is possible because it's backed up by the use of longjmp, you know. > > In the relatively rare case that you have a way of passing a callback > > into Lisp to the library, you either program very defensively in the > > Lisp, > > Always a good idea anyway, at least until thorough testing is done. > > > or just wrap the whole thing in a condition-case (such as > > ignore-errors) before passing it to the library. > > What is the downside of having the Emacs module API do that for you? Well, the very existence of `ignore-errors' is an abomination, you can hardly expect me to condone its automatic use. :-) Suppressing errors screws exactly the non-Emacsy developers it's supposed to help -- the callback code is nearly impossible to debug without the Emacs expertise that we're assuming the module developer *doesn't have*. Also, the expense of an unnecessary condition-case in a tight loop is not to be ignored, when the Lisp-level "no brain required" safety belt for code that might signal but isn't performance-critical is so simple and stylized. But in most modules, we're just using library code to do a calculation, and then we can pass the result (including signaling an error status) back out to Lisp. XEmacs (and even more so SXEmacs) have been doing this a lot over the years. The necessary code is pretty boring, and I've never seen one that involves the nonlocal exit issue. The Lisp APIs that are most frequently used are hard to reduce (DEFUN, DEFVAR). GCPROs (S?XEmacs still uses them) are very rare, and even those can generally be avoided by sticking strictly to the marshalling/unmarshalling in C, and doing Lisp manipulations in Lisp. The problem that Daniel is worried about is real, but I don't see a good way of solving it in Emacs. In any case, it doesn't matter to encouraging use of modules. The vast majority of modules simply won't have callbacks to deal with. People who *want* to write a callback in Lisp and pass it to C are going to be rare, and likely to be experienced Emacs developers, I would think. If not, they're surely multilingual. They probably can deal with it.