Re: Dynamic modules: emacs-module.c and signaling errors

[Eli Zaretskii]

> Cc: address@hidden
> From: Paul Eggert <address@hidden>
> Date: Thu, 26 Nov 2015 13:20:46 -0800
> 
> Eli Zaretskii wrote:
> > It's not obvious to me, sorry.  The costs of the current code are
> > minimal, and the advantages to have the "raw" functionality in
> > addition to what we have aren't clear-cut.
> 
> My admittedly vague impression is that Stefan's approach would be friendlier 
> to 
> module authors who want to write code that feels like Emacs's current C code. 
> This should be a plus, no?

Yes.  I already posted a summary of the differences, and how IMO we
should go about keeping these differences to a minimum.  No one
replied.

> I don't fully understand why the current emacs-module.c is as complicated as 
> it 
> is, to be honest.  I know it has something to do with C++ exception handling, 
> but the details still escape me.  But really, we should support C modules 
> well 
> too, as C is still the lingua franca for low-level software integration.  And 
> "well" does not mean "every time you call a function you then have to call 
> some 
> other function to see whether the first function worked".

This is concealed in emacs-module.c.  Module authors don't need to
know that, or be bothered.  They can simply write code "as usual".

As to emacs-module.c, it's more complicated due to this, I agree.  But
not too complicated, IMO.  And the rules for writing functions in
emacs-module.c are really quite simple, they almost boil down to
having some pretty boilerplate code at the beginning of every
function.  Maybe we even could come up with a single macro that
injects all that code.