From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Emacs rewrite in a maintainable language Date: Mon, 12 Oct 2015 17:24:12 +0200 Message-ID: <87zizo9kkj.fsf@fencepost.gnu.org> References: <561A19AB.5060001@cumego.com> <87io6dl0h0.fsf@wanadoo.es> <87lhb82qxc.fsf@gmail.com> <561BCD40.5040502@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1444663488 30140 80.91.229.3 (12 Oct 2015 15:24:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 12 Oct 2015 15:24:48 +0000 (UTC) Cc: Oleh Krehel , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 12 17:24:48 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 1Zlexu-0000yK-T5 for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 17:24:43 +0200 Original-Received: from localhost ([::1]:56120 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zlexu-0002Qo-78 for ged-emacs-devel@m.gmane.org; Mon, 12 Oct 2015 11:24:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56067) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlexX-00024l-9r for emacs-devel@gnu.org; Mon, 12 Oct 2015 11:24:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZlexW-0007a0-FA for emacs-devel@gnu.org; Mon, 12 Oct 2015 11:24:19 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:41316) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZlexS-0007Xh-Mf; Mon, 12 Oct 2015 11:24:14 -0400 Original-Received: from localhost ([127.0.0.1]:55132 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.82) (envelope-from ) id 1ZlexR-0000KB-Di; Mon, 12 Oct 2015 11:24:13 -0400 Original-Received: by lola (Postfix, from userid 1000) id C4AD1E0F01; Mon, 12 Oct 2015 17:24:12 +0200 (CEST) In-Reply-To: <561BCD40.5040502@cs.ucla.edu> (Paul Eggert's message of "Mon, 12 Oct 2015 08:09:52 -0700") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:191353 Archived-At: Paul Eggert writes: > On 10/12/2015 05:48 AM, Oleh Krehel wrote: >> I've been trying to get into understanding Emacs C core, but it's just >> so hard with all those macros around. > > I dislike those macros too, and have gotten rid of more than my share > of them, typically replacing them with inline functions (e.g., XFLOAT) > or with enum constants (e.g., BITS_PER_CHAR). Much more work could be > done in this area. This part largely doesn't need C++, and the few > places where it might benefit from C++ typically require so much C++ > foo that it's not clear it's worth the hassle. > > I suppose the main advantage of C++ over C, for something like the > Emacs core, would be encapsulation. But here again, it's not clear > that C++ would be enough of a win. The ways in which the Emacs core > are poorly encapsulated are largely independent of C vs C++. Changing > it to be better-encapsulated C++ would not be that much of a win over > changing the current Emacs to be better-encapsulated C. > > Of course all of this is sheer speculation. I haven't attempted > rewriting major sections of the Emacs core into C++ and I suspect > nobody else has either. Until that is attempted, we're just > guessing. (And I'm not volunteering!) LilyPond is using C++ and I replaced a macro system for defining GUILE's Scheme objects (smobs) and a macro system for defining message-passing protocols with C++ constructs. Part of the reason was that when using this macro system in connection with C++ inheritance, the code just bombed out with indecipherable symptoms either at compilation or, worse, execution time and it was quite impossible to figure out what the code actually did after preprocessing. The main incentive here was to replace large conceptual complexity (not adequately represented by C macros) with constructs more accessible to the average programmer, and constructs that were understandable to GDB and C++ and that were not bypassable with other ad-hoc code (C macros obviously can just be spelled out). In the context of doing that, there were a few deadlocks in our development because the compiler requirements increased and we had to update all of our cross-compiling environment. There also were some language and crosscompiling issues, as well as some hiccups with people using Clang. The C macros used within Emacs are not of a similar complexity and type-madness. I don't see that changing them to C++ constructs will deliver enough of a return to justify the price. -- David Kastrup