Re: Emacs rewrite in a maintainable language

[David Kastrup <dak@gnu.org>]

Paul Eggert <eggert@cs.ucla.edu> 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