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

[Alan Mackenzie <acm@muc.de>]

Hello, Paul.

On Mon, Dec 10, 2018 at 15:54:02 -0800, Paul Eggert wrote:
> 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?

Yes.

> If so, that sounds error-prone. C is notoriously tricky to
> preprocess, ...

You don't need to tell me that.  ;-)  However, all this preprocessor
would do would be to recognise starts and ends of functions from a list
of known functions, and textually substitute BC_foo for foo, again from
that list of known substitutions.  It would need to parse comments and
strings.  The list of known functions can be reliably generated by
objdump (from binutils).

This preprocessor would be tedious rather than difficult to write.

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

Because the two interpreters will need to share file static data, of
which there must be only one copy.  So the two versions of each function
need to be in the same "source" file.

The approach has the advantage that only minimal amendment of the C
source, if that, will be needed.

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

Yes, we'd all like that, but several weeks of exploring alternatives has
failed to produce any workable solutions on these lines.

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

Not really, no.  To recap, that would involve the reader adding
annotations to every Lisp element, turning it into a list looking like:

    (locinfo FILE POS (foo (locinfo FILE POS a) (locinfo FILE POS 4)))

in place of

    (foo a 4)

.  The form Stefan suggested is MUCH bigger than the plain form, having,
perhaps four times the number of conses (I haven't counted them).  A
large part of the compiler would need to be amended to cope with the new
format, even supposing it could work with macros (which I don't think it
could).  This amendment would be uninspiring and tedious in the extreme.

I seriously doubt this would run faster than the symbols-with-position
approach (which has already been implemented), even if it could be made
to work.

> for more info, see Gemini's followup
> <https://lists.gnu.org/r/emacs-devel/2018-12/msg00043.html>.

I've read this several times.  It suffers the same drawbacks as Stefan's
idea.  In particular it doesn't give any idea how the compiler would
operate on the proposed forms.

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

I don't think it would work, either.  That idea is for macros' uses of
eq to be replaced by BC-eq inside the macro.  The trouble is, many uses
of eq are actually expansions of EQ in the C code (e.g. in Fequal,
Fassq, ....) and they would all need modifying too, and we're back in
the same situation of having an alternative interpreter.

-- 
Alan Mackenzie (Nuremberg, Germany).