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 loading progress Date: Sat, 14 Feb 2015 19:22:21 +0200 Message-ID: <83fva8wgqa.fsf@gnu.org> References: <85oapy5kt6.fsf@stephe-leake.org> <83y4oiiw81.fsf@gnu.org> <838ugdf251.fsf@gnu.org> <54D80098.3020209@cs.ucla.edu> <54D85304.1030600@cs.ucla.edu> <54D9AC29.2020603@cs.ucla.edu> <54DA8539.1020905@cs.ucla.edu> <87zj8ktq8f.fsf@lifelogs.com> <54DD6413.1000403@cs.ucla.edu> <83wq3m436s.fsf@gnu.org> <54DDEB4D.5040300@dancol> <83egpt4zz6.fsf@gnu.org> <54DE12E9.5040606@dancol.org> <85twypiiug.fsf@stephe-leake.org> <83zj8g3n16.fsf@gnu.org> <87twyolm8k.fsf@uwakimon.sk.tsukuba.ac.jp> <833868y8hf.fsf@gnu.org> <87sie8l9ql.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1423934618 25305 80.91.229.3 (14 Feb 2015 17:23:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 14 Feb 2015 17:23:38 +0000 (UTC) Cc: stephen_leake@stephe-leake.org, emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 14 18:23:30 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 1YMgRF-0005rZ-Jp for ged-emacs-devel@m.gmane.org; Sat, 14 Feb 2015 18:23:29 +0100 Original-Received: from localhost ([::1]:60613 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMgRF-0006sw-3e for ged-emacs-devel@m.gmane.org; Sat, 14 Feb 2015 12:23:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44294) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMgR7-0006rs-F6 for emacs-devel@gnu.org; Sat, 14 Feb 2015 12:23:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMgR2-0005va-JM for emacs-devel@gnu.org; Sat, 14 Feb 2015 12:23:21 -0500 Original-Received: from mtaout24.012.net.il ([80.179.55.180]:38728) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMgR2-0005vC-6C for emacs-devel@gnu.org; Sat, 14 Feb 2015 12:23:16 -0500 Original-Received: from conversion-daemon.mtaout24.012.net.il by mtaout24.012.net.il (HyperSendmail v2007.08) id <0NJR00M00UH2WZ00@mtaout24.012.net.il> for emacs-devel@gnu.org; Sat, 14 Feb 2015 19:14:03 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout24.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJR00H1YUJFHG50@mtaout24.012.net.il>; Sat, 14 Feb 2015 19:14:03 +0200 (IST) In-reply-to: <87sie8l9ql.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.180 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:183068 Archived-At: > From: "Stephen J. Turnbull" > Cc: stephen_leake@stephe-leake.org, > emacs-devel@gnu.org > Date: Sun, 15 Feb 2015 01:48:50 +0900 > > Eli Zaretskii writes: > > > > I don't understand. XEmacs's ELLs (dynamically loadable modules) > > > have no problem with calling Lisp (use Ffuncall) or using symbols > > > (use Fintern). The only requirement that I've seen expressed in > > > this thread that XEmacs ELLs don't satisfy is that a module > > > should be compilable for use with multiple versions of XEmacs > > > > This last requirement is what is being discussed here. The capability > > of creating Lisp objects depends on the internals, and AFAIU we would > > like to avoid having that dependency. > > It's not very hard to get backward compatibility (old compiled modules > work in new Emacs). Define a stable ABI, and then stick to it. I simply don't believe this goal to be practically achievable, if there are no limitations on the interface. I also am not sure that people would accept forward incompatibility easily: consider the number of people who use bleeding-edge Org, Gnus, etc. with the last official release of Emacs. Why would they agree to lose that when part of a module is in C? > It shouldn't be that hard to do it. Most Lisp functionality of most > types is accessed through the object header, which points to a class > descriptor, which is basically a table of methods. In XEmacs there's > a constructor, a finalizer (optional), a printer, a gc-marker > (optional), and a couple of others I forget offhand. Add a length > indicator at the beginning, never change the order of methods from > past versions, and I think you're done. If you add new methods in new > Emacs, no problem, just add them at the end of the table. If you > deprecate old ones, just leave the slots and insert an unimplemented > marker (probably (slot_fun *) NULL will do but you could get fancy and > have a slot_deprecated_fun to put in that slot). Sure, unneeded slots > may accumulate over time, but you're going to have only a few dozen > types at most and a couple unused slots per type. Emacs objects aren't built that way, so part of what you say is inapplicable. But the real problems don't happen at that level, they are elsewhere, see below. > Then require that module functions access other modules (including > core) only through Lisp (ie, Ffuncall and Fintern), which has a very > stylized calling convention. And what about accessing Lisp objects? Most of them are accessed through C macros, whose definitions change as the internals change. What can you do with those to preserve compatibility across Emacs versions? > > I wasn't talking about using Lisp by modules, I was talking > > specifically about calling Lisp from C. Implementing new > > primitives for performance purposes doesn't need that, at least it > > isn't clear to me why it would. > > I just don't see what the problem is. We call Lisp from C all the > time, that's what Ffuncall *is*. It appears in most backtraces. :-) It appears in most backtraces because the Lisp interpreter calls it when it sees funcall in Lisp. More to the point: I simply don't see any reason for calling Lisp from C. If a module needs to do something in Lisp, let it do it in Lisp directly, as every external package for Emacs does. C code should be reserved for providing additional primitives that core Emacs lacks, and that's all. At least that should be the starting point, IMO.