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

[Alan Mackenzie]

Hello, Paul

On Tue, Nov 27, 2018 at 17:11:48 -0800, Paul Eggert wrote:
> On 11/27/18 1:53 PM, Alan Mackenzie wrote:
> > Macros would mess things up. For example, after expanding a macro like 
> > the contrived
> >     (defmacro dehash (form)
> >       (copy-tree form))

> > , how would the recorded cons locations be linked up with the resulting
> > form?

> People typically don't write macros like that, ....

For the pertinent value of "like", they do.  The essential feature of
that macro is that it returns a list form whose conses are not the input
conses.

In a typical macro, only some of the conses survive the processing.  For
example, every time the macro result is something like:

    `(progn ,@(mapcar 'foo body))

, the conses in the return list are new, and the old conses are lost.
Look at cconv-closure-convert.  I know this isn't, strictly speaking, a
macro, but it rearranges code the way macros do.  In its output there
isn't a single cons which was present in the input.

> .... so we needn't tune our design for it.

It's not a matter of "tuning" the design.  It's a matter of having a
scheme which will work at all.

> .... More commonly, people write macros containing errors, such as:

>    (defmacro face-attribute-specified-or (value default &rest body)
>      (let ((temp (make-symbol "value")))
>        `(or
>           (let ((,temp ,value))
>             (if (eq ,temp 'unspecified)
>                 (progn ,@body)
>               default))
>           ,temp)))

> This has a parenthesization typo and the macro doesn't mean what the 
> user probably intended. For these macros, as I understand it the 
> symbols-with-pos approach messes up because the symbol associated with 
> the error was built by make-symbol and doesn't have a source code 
> position.

It doesn't "mess up".  It's that the compiler isn't designed to give
warning messages about already compiled macros being used, and this is
the case regardless of whether symbols-with-pos or conses-with-pos is
used.  To change this is a separate question which we should deal with
separately, if at all.

> In contrast, the cons-with-pos approach should return a good location
> in the macro itself for the undeclared symbol (i.e., just before the
> last ",temp").

No.  Assuming the macro is compiled, just where are these cons positions
going to be stored?  Byte compiled functions/macros don't consist of
conses.  Merely evaluated functions/macros do consist of conses, but
they also consist of symbols, so ons-with-pos doesn't come out ahead,
here.

Anyhow, this is all a diversion from the main point, which is how to
generate warning positions for the source currently being compiled.

> One can also come up with examples where the symbols-with-pos approach 
> is better than the cons-with-pos approach. That is, neither approach 
> dominates the other.

You're wrong, here.  Symbols-with-pos works on the output from macros.
Conses-with-pos will only do so for some "nice" macros, ones which
preserve their input conses.

> So, which approach would be better in practice? I don't think we know.

Well, in practice, the symbols-with-pos approach exists and works, even
if it is currently unfinished.  cons-with-pos has been tried, by me, and
never reached anything like a working version.  I'm convinced the idea
can't work.

Maybe it needs somebody more capable than me to implement cons-with-pos.

#########################################################################

> > the "slow" Emacs would somehow need to be used by the byte compiler 
> > after Emacs has been built, to continue to get accurate warning locations.

> That's easy enough: the fast Emacs can fork and exec the slow one, which 
> can be installed next to movemail etc. (Again, not that I like this 
> approach.)

Thinking about it, what other approach is there?  Because of the ~6728
macro calls of EQ, NILP, .... scattered throughout the Emacs sources,
almost all that source will need to be compiled twice, and one way or
another be made available to users in two forms.

-- 
Alan Mackenzie (Nuremberg, Germany).