Re: Reporting Lisp errors in dynamic modules

[Philipp Stephani <p.stephani2@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]

Eli Zaretskii <eliz@gnu.org> schrieb am Fr., 27. Nov. 2015 um 12:07 Uhr:

> With the latest emacs-25 branch, load modules/mod-test/mod-test.so,
> then evaluate '(mod-test-sum "1" 2)'.  The backtrace that pops up is
> this:
>
>   Debugger entered--Lisp error: (wrong-type-argument integerp "1")
>     #<subr module-call>(#<save-value <pointer 00fdab90> <unused> <unused>
> <unused>> ("1" 2))
>     mod-test-sum("1" 2)
>     eval((mod-test-sum "1" 2) nil)
>     elisp--eval-last-sexp(nil)
>     eval-last-sexp(nil)
>     funcall-interactively(eval-last-sexp nil)
>     call-interactively(eval-last-sexp nil nil)
>     command-execute(eval-last-sexp)
>
> I believe the line with "<subr module-call>" is suboptimal, in that it
> looks alien and includes all kinds of unneeded and weirdly formatted
> data.  AFAIU, the reason is that we deliberately unintern module-call.
> Should we perhaps reconsider that decision, so that the backtrace is
> in more familiar form?  What exactly are the dangers of having
> module-call exposed as any other primitive?
>

- Somebody calls it with the wrong type. Right now it doesn't do any type
checking, so that would crash/be UB.
- An existing function outside of Emacs might already be called like that.

Those are really minor issues, but since module-call is unusable from Lisp
or module code anyway, I've decided to avoid them by uninterning it. If
type checking is added and the name clash issue is consider minor,
interning it is fine.

A cleaner approach would be to define module functions as separate kind of
function object. I think right now we have lists (Lisp closures and
lambdas), subrs, and bytecode objects, module functions could be a fourth
type. But that would require more thorough changes.

[-- Attachment #2: Type: text/html, Size: 2262 bytes --]