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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

> Hash tables for cons locations would work well enough, if someone had the
> time to put into it.

Experiment with this approach seemed to indicate that it would slowdown
compilation tremendously (not just a few percents) because of the cost
of all those hash table operations.

> The main objection seems to be that the byte-compiler would lose track
> of location information.  But we can fix the byte-compiler so that it
> doesn't lose track of the location information.  That's purely
> a byte-compiler issue, which is a good thing for software engineering
> reasons as well as for performance reasons.

I agree that making modifications to the byte-compiler is fundamentally
what we want to do.  My current thinking is that we could try to do
something like the following:

`read-with-positions` could return annotated-sexps that would look like:

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

for an input like

    (foo a 4)

It would significantly increase the size of the sexp and hence incur
a slowdown, but it won't be nearly as bad as with the hash-table hack.
Preservation of this info through the byte-compiler itself wouldn't
take too much effort (most of the code can treat `locinfo` as a kind of
function which returns its 3 argument).

The main problem is for macro expansion: when we call a macro we can't
pass it these annotated sexps, so we have to de-annotate the sexp
arguments, which is both extra work and a loss of important info.

So I was thinking of reducing the pain by re-using the edebug info so as
to find those arguments (or parts of arguments) which are treated as
normal expressions, which we don't need to de-annotate.

FWIW, these are just idle thoughts.  I don't really have the intention
to work on it in the foreseeable future.


        Stefan