[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Reporting Lisp errors in dynamic modules

From: Eli Zaretskii
Subject: Re: Reporting Lisp errors in dynamic modules
Date: Fri, 27 Nov 2015 19:39:45 +0200

> From: Philipp Stephani <address@hidden>
> Date: Fri, 27 Nov 2015 16:40:23 +0000
> Cc: address@hidden, address@hidden, address@hidden
>     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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]