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: Sun, 15 Feb 2015 17:03:21 +0900 Message-ID: <87pp9blhyu.fsf@uwakimon.sk.tsukuba.ac.jp> 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> <83fva8wgqa.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Trace: ger.gmane.org 1423987441 28214 80.91.229.3 (15 Feb 2015 08:04:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Feb 2015 08:04:01 +0000 (UTC) Cc: stephen_leake@stephe-leake.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 15 09:03:53 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 1YMuBB-0004VO-OY for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2015 09:03:49 +0100 Original-Received: from localhost ([::1]:33826 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMuBB-0001OS-15 for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2015 03:03:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45057) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMuAv-0001OL-5D for emacs-devel@gnu.org; Sun, 15 Feb 2015 03:03:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YMuAt-0005eU-QA for emacs-devel@gnu.org; Sun, 15 Feb 2015 03:03:33 -0500 Original-Received: from shako.sk.tsukuba.ac.jp ([130.158.97.161]:41134) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YMuAo-0005dg-5H; Sun, 15 Feb 2015 03:03:26 -0500 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by shako.sk.tsukuba.ac.jp (Postfix) with ESMTPS id 776CD1C38A2; Sun, 15 Feb 2015 17:03:21 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 538911A26E3; Sun, 15 Feb 2015 17:03:21 +0900 (JST) In-Reply-To: <83fva8wgqa.fsf@gnu.org> X-Mailer: VM undefined under 21.5 (beta34) "kale" acf1c26e3019 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:183082 Archived-At: Eli Zaretskii writes: > > From: "Stephen J. Turnbull" > I simply don't believe this goal to be practically achievable, if > there are no limitations on the interface. The limitation is obvious: in principle, all Lisp objects are accessed through Lisp, with the exception of numbers. Even for strings and buffers you can call Lisp "coding system" functions. You may need to add an "internal char[] buffer" type to serve as source/sink (I'm sure you already have one for stream I/O, but it probably doesn't have a formal or stable definition). > 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? For the same reasons they do when a package decides to use some new feature of Lisp that is forward incompatible. Mostly, they have no choice if the package decides to do that. Upgrade their Emacs or lose out. But I don't think you need to worry that the package maintainers will gratuitously break compatibility for users of C modules. If Emacs is unwilling to be disciplined, package maintainers won't use C modules, or will call through Lisp and otherwise treat external Lisp objects as opaque. > 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? Prohibit such change, or add accessor functions with a stable ABI encapsulating the accessor macros to a table for use by externally compiled modules loaded at runtime. A C function call is very cheap compared to a Lisp funcall. If this is too expensive the module probably shouldn't be based on Emacs at all, or it can be moved into core as has been done traditionally. It's that simple, both as a constraint on core development and as a software engineering technique. This is not rocket science, and hasn't been for a decade and a half now. It's just work, which the core developers can and should impose on the folks who want the feature. If you expect you must change some ABI in the future and can't/won't use the method table approach, tell module writers to access them *through* Lisp and live with funcall overhead. I assure you there are plenty of features that can benefit from C code that can live very happily even with that restriction. > 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. But you're not the one who wants this feature. The people who do want this feature, in both XEmacs (which has more than a decade of experience with ELLs) and now in Emacs, have accessed, or think they need to access, Lisp objects from their C code.