Re: Reporting Lisp errors in dynamic modules

[Eli Zaretskii <eliz@gnu.org>]

> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Fri, 27 Nov 2015 16:40:23 +0000
> Cc: aurelien.aptel+emacs@gmail.com, tzz@lifelogs.com, dancol@dancol.org
> 
>     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.

We can add checks to countermand that.

> - An existing function outside of Emacs might already be called like that.

Not really a problem, IMO.

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

OK, I will see what I can do, thanks.

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

Yes, indeed.