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

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 10 Dec 2018 19:35:57 +0000
> Cc: emacs-devel@gnu.org
> From: Alan Mackenzie <acm@muc.de>
> 
> > Then how about invoking this alternative interpreter only if the prime
> > interpreter detected a warning or error while byte-compiling?  You
> > could invoke the alternative interpreter only on the form where the
> > problem was detected, with the goal of "drilling down" to find the
> > exact position of the problematic symbol(s).
> 
> That would mean starting the byte compilation with no position
> information being gathered, and then when an warning occurs, aborting
> the compilation and starting again from scratch with the position
> information being gather and alternative interpreter being used.

Not necessarily.  It could mean invocation of a special code whose
goal is to find the position of an error in a given form.  The
position of the beginning of this form will have been known, as AFAIU
the existing byte compiler does collect that, or has means to
determine that.

> The problem is, that we cannot use #<symbol nil at 666> in the normal
> interpreter, since it is not EQ nil there.

I'm not sure you must use symbols with positions in the above
arrangement, you could simply invoke special-purpose code that
analyzed the problematic form.  But if you do need to use symbols with
positions, you could do this only when looking for error position, so
other symbol comparisons will not be affected.

> I understand the idea, yes.  But given the timings I measured in the
> existing scratch/accurate-warning-pos (IIRC, around 11% - 12% for an
> actual compilation) and the fact that in the alternative interpreter,
> the slowdown will be somewhat less (one fewer flag comparison per EQ,
> NILP, ...., and we can drop the traditional alist of symbols and
> positions which is running alongside the new symbols with position) it
> may not be worth the extra complexity.

Yes, but what you suggested as the implementation of the alternative
interpreter includes a heck of complexity of its own, IMO.  The idea I
proposed doesn't even require changes in basic types, it could
hopefully be implemented with "normal" Lisp.