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

[Yuri Khan]

On Sun, Dec 2, 2018 at 12:51 AM Clément Pit-Claudel
<address@hidden> wrote:

> IIUC, your code's strategy is to attach location info to symbols as they are 
> read; this is a clever trick, because macroexpansion tends to preserve 
> symbols more than it preserves conses (interestingly, Racket macros are given 
> syntax objects that include position information instead of raw SEXPs for 
> precisely this reason).  But, again IIUC, attaching position information on 
> symbols means that they cannot be compared using pointer equality anymore, 
> which means that EQ must get slower.  I wonder: after byte-compiling and 
> reporting accurately-positioned warnings, couldn't we strip position 
> information from symbols, so that usual Emacs execution isn't affected? The 
> idea would be to start by reading in symbols with position information, 
> preserve this position information throughout byte-compilation, and then 
> strip it so that the rest of the code can use raw pointer equality.

I am wondering about the same thing. The simplified view of the
process would be:

* Parse text into position-annotated AST
* Analyze the position-annotated AST for errors and warnings,
outputting accurate positions
* Byte-compile position-annotated AST, stripping annotations in the process

The complication is that parsing may invoke macros, some of which use
‘eq’ and cannot be recompiled to use ‘eq-with-position-information’.
*If* that latter assumption is true, this complication could be solved
by an opt-in property: A macro that has a 'position-aware property on
it can be called directly on the position-annotated AST and expected
to use ‘eq-with-position-information’; while a legacy macro will be
called on a de-annotated AST, may use plain ‘eq’, and will return a
similarly position-oblivious AST. The parser will then slap its best
guess of position on the root of the macro’s output and say “well, I
tried”.

This way, when people say “I’m getting an incorrect warning position”,
the first question will be “which macros do you use?”, and the second,
“have they been updated to support source positions?” Then people will
go ask those macros’ authors to update them, and/or write new
position-aware implementations.