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

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

> That's too bad. Why is hashing so slow? Can we speed it up?

Possibly.

> Another possibility is to have a special hashing mechanism just for pairs
> that are allocated to be hashable. This would work by having a special
> alternative to struct cons_block for which it would be trivial to convert
> the address of a hashable pair to the address of the corresponding value
> (simply add a constant to the address, say). The new 'read' function could
> return hashable pairs. A hashable pair would have the same structure as an
> ordinary pair so all existing functions (including C macros) would work with
> it. This should be fast enough.

If we only do it for cons cells, then we don't need hashing: we can make
"fat-cons-cells" which contain extra position info after car/cdr.

>> 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.
> Hmm, I know little about edebug so I'm afraid this suggestion is mostly
> Greek to me.

E.g. for a macro like `when` where the edebug spec is just `t` (which
means all the arguments are Elisp expressions) we don't need to
de-annotate anything at all.  And for `dolist` whose edebug spec is
((symbolp form &optional form) body), we can use that debug spec to find
that the first arg needs to be partially de-annotated, and the rest can
be left fully annotated.


        Stefan