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: Sun, 15 Feb 2015 19:33:25 +0200 Message-ID: <83mw4fulju.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> <83fva8wgqa.fsf@gnu.org> <87pp9blhyu.fsf@uwakimon.sk.tsukuba.ac.jp> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1424021625 12242 80.91.229.3 (15 Feb 2015 17:33:45 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 15 Feb 2015 17:33:45 +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 Sun Feb 15 18:33:37 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 1YN34a-0002YP-HR for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2015 18:33:36 +0100 Original-Received: from localhost ([::1]:36098 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN34Z-0008R1-UJ for ged-emacs-devel@m.gmane.org; Sun, 15 Feb 2015 12:33:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56667) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN34T-0008Qr-2V for emacs-devel@gnu.org; Sun, 15 Feb 2015 12:33:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YN34N-0000TD-Rf for emacs-devel@gnu.org; Sun, 15 Feb 2015 12:33:29 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:42662) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YN34N-0000T6-EH for emacs-devel@gnu.org; Sun, 15 Feb 2015 12:33:23 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NJT00900Q2N6S00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Sun, 15 Feb 2015 19:33:22 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NJT009NPQ3L0140@a-mtaout20.012.net.il>; Sun, 15 Feb 2015 19:33:22 +0200 (IST) In-reply-to: <87pp9blhyu.fsf@uwakimon.sk.tsukuba.ac.jp> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 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:183096 Archived-At: > From: "Stephen J. Turnbull" > Cc: stephen_leake@stephe-leake.org, > emacs-devel@gnu.org > Date: Sun, 15 Feb 2015 17:03:21 +0900 > > > 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 Not sure what that means in practice. What would be the definition of a Lisp_Object visible to a module? Will it be what we have on lisp.h, or some opaque object? > with the exception of numbers. Why the exception? What if the internal representation of a number changes? (It already did, a few weeks ago.) > 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 don't follow: why coding-systems are relevant here? Perhaps you have XEmacs implementation in mind. > > 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. Using Lisp objects is not a new feature, so I don't think this analogy will hold water. > 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. I think they will rather apply pressure to avoid changes that break binary compatibility, which in the long run will limit development. Not sure if we want that; something to discuss, I guess. > > 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. That's what I tried to do in my suggestion for the API, but I don't hold my breath to see it accepted. Stephen Leake already said he didn't like it; I have no reason to believe I will hear anything different from others. The way the current modules on the branch are written are a good sign of what will follow, I think. > 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. How can funcall help you access Lisp objects and convert their values to something that C can grok? Sooner or later, you will have to access the internals of the objects. So the funcall issue is irrelevant to accessing Lisp objects. > > 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. Yes, I understand that. And because of that I don't believe the "stable API" paradigm will be accepted. I think people will want to write modules with the same freedom and flexibility we write core code. Which means the "tightly-coupled" paradigm.