Eli Zaretskii <
address@hidden> 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.