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

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> >> Because this loses the connection between the signal and its origin.
>> > Not really, it doesn't.  You get the same Lisp error you'd get in
>> > Emacs proper.
>> That's only the signal, not its origin.  Its origin is lost.
> Not sure what you mean by that.  The origin is clearly stated in the
> error message.

You mean debug-on-error will properly show me the right stack state and
let me look up and change the corresponding variables?
Hmm... didn't think so.

>> >> Because it imposes a cost which we may not want to pay.
>> > What cost is that?
>> Catch and then rethrow.  Which is pure cost with no benefit, if you ask me.
> A cost very close to zero.

Who cares.  Still pure cost with no benefit.
The core provides naturally a plain raw non-catching funcall, but with
the current design a module author who wants this behavior can't have it
because the module API hides it behind some "idiot-proofed layer", so
the best the module author can do is add yet another layer to try and
reproduce as best it can the underling non-catching funcall behavior.

This is completely dumb.

> No one needs to do anything, the code is already written, and module
> authors don't even need to know it exists, or what exactly does it do.

The criteria to accept bad design shouldn't be "does the code
already exist?".

> 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.

As I said, we have plenty of experience in Emacs's own source code:
look in Emacs's source code and compare the number of uses of
"safe_call" and friends to the number of uses of "callN" and friends.
The catching version is useful at times, but it's the exception rather
than the rule.  XEmacs's experience is the same, apparently.


        Stefan