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

[Alan Mackenzie <acm@muc.de>]

Hello, Paul.

On Sun, Nov 25, 2018 at 10:45:09 -0800, Paul Eggert wrote:
> I didn't realize until now that this branch makes EQ slower for everybody, ....

Yes.  That is why I have been so concerned about the speed, right from
the beginning.

> .... for what seems to be a relatively minor issue (i.e., more accurate
> diagnostics). ....

Well in the branch I'm working on, there are 335 warnings with a
position, and the old way of doing things gave the correct position in
only 81 of these, being wrong in the other 254.

There have been quite a lot of bug reports about wrong warning positions.

> Surely there is a better way.

Stefan, Eli, and I had quite an extensive discussion about possible
approaches two or three or four weeks ago.  Our conclusion (formulated by
me) was that there was no good way of resolving the bug, only varying
degrees of bad ways.

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

> Why not add an option to 'read' so that its returned value contains 
> symbol-with-pos objects instead of symbol objects?

That's more or less what's been done, except that there's a second
function called read-positioning-symbols alongside read.

> That way, programs like the Elisp compiler that read objects can
> generate more accurate diagnostics without having to slow down EQ for
> everybody.

The problem is that when compilation is in progress,

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

has got to return t.  I can't see a better way of doing this than testing
the variable symbols-with-position-enabled at each failing == operation.

If you have any better suggestions, I'd love to hear of them.

-- 
Alan Mackenzie (Nuremberg, Germany).