Re: scratch/accurate-warning-pos: next steps.

[Paul Eggert]

On 12/10/18 10:00 AM, Alan Mackenzie wrote:
> lisp.h would be modified to define alternative versions of EQ, NILP,
> SYMBOLP, and XSYMBOL, and alternative versions of the INLINE functions
> which call them.  These would be called BC_EQ, BC_NILP, BC_SYMBOLP, and
> BC_XSYMBOL.
>
> Most of the C sources would, at build time, be fed to a preprocessor
> which would analyse (almost every) C function, and write a temporary file
> containing the functions foo and BC_foo next to eachother.

This preprocessor would be a separate program that we'd write? If so, 
that sounds error-prone. C is notoriously tricky to preprocess, and 
Emacs already uses the C preprocessor aggressively. Instead, why not use 
the C preprocessor itself, rather than writing another preprocessor for 
C? In other words, compile each file twice, once with one -D option and 
once with another.

Even with this suggestion, though, I'm leery of multiple interpreters. 
Although it'd be better to have multiple interpreters (one faster, one 
slower) than to have just a single, slower interpreter, it'd be better 
yet to have just a single, faster interpreter.

Instead, I suggest looking into Stefan's suggestion to use edebug info 
<https://lists.gnu.org/archive/html/emacs-devel/2018-11/msg00526.html>, 
which should be a much less-drastic way to address the problem; for more 
info, see Gemini's followup 
<https://lists.gnu.org/r/emacs-devel/2018-12/msg00043.html>. 
Alternatively, Yuri's suggestion of an opt-in property for macros 
<https://lists.gnu.org/r/emacs-devel/2018-12/msg00023.html> also seems 
like a much-simpler approach that should work just as well in the long 
run as multiple interpreters would.