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 11:56:16 +0900 Message-ID: <8737ygz8z3.fsf@uwakimon.sk.tsukuba.ac.jp> References: <86d1yirnqw.fsf@stephe-leake.org> <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: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1442285810 5517 80.91.229.3 (15 Sep 2015 02:56:50 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 15 Sep 2015 02:56:50 +0000 (UTC) Cc: Paul Eggert , Emacs development discussions , Philipp Stephani , Stefan Monnier , =?utf-8?Q?Aur=C3=A9lien?= 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 04:56:40 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 1ZbgQC-0007qt-34 for ged-emacs-devel@m.gmane.org; Tue, 15 Sep 2015 04:56:40 +0200 Original-Received: from localhost ([::1]:44699 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbgQA-000629-TT for ged-emacs-devel@m.gmane.org; Mon, 14 Sep 2015 22:56:39 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41199) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbgPx-00061q-DX for emacs-devel@gnu.org; Mon, 14 Sep 2015 22:56:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZbgPs-0005LU-E1 for emacs-devel@gnu.org; Mon, 14 Sep 2015 22:56:25 -0400 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:43559) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZbgPs-0005Ha-50 for emacs-devel@gnu.org; Mon, 14 Sep 2015 22:56:20 -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 019161C38FC; Tue, 15 Sep 2015 11:56:17 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id CC0A611EF83; Tue, 15 Sep 2015 11:56:16 +0900 (JST) In-Reply-To: <55F6E43E.9030502@dancol.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:189963 Archived-At: Daniel Colascione writes: > Calls back to Emacs functions will be fairly common, because > modules use these functions to manipulate Emacs data on behalf of > their own callers. Real examples, please. S?XEmacs has two decades of experience with wrapping random libraries, Emacs has some too, and there just aren't any that I can think of offhand. I see no reason why modules in Emacs will change that pattern; S?XEmacs has a 1.5 decades of experience with require'able modules, and it hasn't changed there. > Who will be common, because the entire point of writing modules is > to work with the _non_-Emacs world. I can imagine one module that > has both non-trivial calls back into Emacs and quite a bit of > internal state in suitable for management with Emacs > primitives. It's called Python. You have a serious licensing problem, I think, which is one of the important reasons why we haven't seen very much in the way of complex integration in the past. But be that as it may.... You're kidding, right? I can't imagine that somebody with the skills in both Python and Emacs and the energy and time needed to write the kind of deep integration you're talking about would be deterred by the need to adapt a couple score lines of "suggested code" to their preferred conception of error handling. Of course it will be hard to write the boilerplate the first time, but by the same token the first try will undoubtedly suck. So the implementation will *change* to fix the suckiness. If the boilerplate is embedded in the module API it will likely force the modules to update to work with the new rules. I think a module that seems to be working well is very unlikely to be pleased by such churn. So, you could be right in the long run, but I think it's the better part of valor to not restrict modules in that way now. Instead, put the responsibility for error handling the callback itself first. Modules that want to can provide their own child-proof wrappers. After experience incorporate the best (plural, if appropriate) of those wrappers in Emacs itself, either embedded in the module API or as an optional standard wrapper. > safe_call blindly suppresses errors. Errors from module-invoked > functions to propagate normally from the perspective of surrounding > Lisp code. Show us the code to "propagate errors normally to surrounding Lisp code". XEmacs has its own safe_call-type functions that do somewhat better than merely suppressing all errors, but they're heavy and hard to use correctly -- and there we know at least that the calling side of the call is XEmacs (the other side is typically low-level I/O code that uses Lisp to format output or parse input). But for modules, since callbacks can be anything and the callback will be separated from the "surrounding Lisp code" by arbitrary amounts of non-Lisp code doing unknown things, I doubt you can do "normal". But let's see how close you can get.