Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps.

[Alan Mackenzie <acm@muc.de>]

Hello, Paul.

On Sun, Nov 25, 2018 at 12:12:56 -0800, Paul Eggert wrote:
> Alan Mackenzie wrote:

> > How do other Lisp compilers work?  They must have ways of keeping track
> > of line and column numbers.

> I'm pretty sure they don't redefine the meaning of 'eq'....

Maybe, maybe not.  How do they actually do it?  I simply don't know, I
thought you might.

As I said, when we discussed this bug a few weeks ago, we could only
come up with bad ways of dealing with it.  The current bad way has the
advantage of being practical and implementable.

> > The problem is that when compilation is in progress,

> >      (eq 'foo '#<symbol foo at 666>)

> > has got to return t.

> Why not change the byte-compiler to use 'eq-ignoring-symbol-pos' (or
> whatever you want to call it) instead of 'eq'?

Because of macros.  These macros are typically already compiled.

> The byte compiler could do this for every occurrence of 'eq' in every
> user macro, ....

No it couldn't.  In this context, "user macro"s include any helper
defuns that they call.  They would need to be converted, too.  To say
nothing of quite a few standard Emacs functions, probably.  I've no idea
how any of this could be done, but suspect it would be more work than
reimplementing the byte compiler from scratch.

> .... as well as in its own code. This should let ordinary Lisp code
> run at full speed; only compilation would be slowed down.

The actual slow down is currently uncertain.  On benchmarks, Gemini
Lasswell has measured between 1% and (?)30% slowdown.  On realistic
applications (a make bootstrap and scrolling through xdisp.c) I've seen
7 to 8% slowdown.

If you could come up with a solid proposal which would fix the bug
without slowing down Emacs at all, we'd all be most appreciative.

One of the bad ways of dealing with the bug was not to bother fixing it
at all.  Given how poor the current method is (under 25% hit rate in a
bootstrap), I don't think this is a good idea.

-- 
Alan Mackenzie (Nuremberg, Germany).