Re: scratch/accurate-warning-pos: next steps.

[Paul Eggert <eggert@cs.ucla.edu>]

On 12/11/18 3:34 AM, Alan Mackenzie wrote:

 > The list of known functions can be reliably generated by objdump 
(from binutils).

Would objdump be run on every build that compiles a .c file that goes 
into the Emacs executable? If so, aren't we limiting builds to platforms 
that have binutils, which would be a new restriction? And if not, 
wouldn't the objdump use be a hand-done process that would need to be 
redone on a binutils platform (with output committed to Git) whenever a 
significant-enough change is made to src/*? Either way, this sounds like 
a hassle.


 >> .... and Emacs already uses the C preprocessor aggressively. 
Instead, why not use the C preprocessor itself, rather than writing 
another preprocessor for C? In other words, compile each file twice, 
once with one -D option and once with another.
 >
 > Because the two interpreters will need to share file static data, of 
which there must be only one copy. So the two versions of each function 
need to be in the same "source" file.

It should be easy enough to move shared file-static data into another 
file, that would be compiled only once. We don't have so much shared 
file-static data that this would be a major obstacle.


 > The form Stefan suggested is MUCH bigger than the plain form, having,
 >
 > perhaps four times the number of conses (I haven't counted them).

This overhead would occur only when byte-compiling the form, which 
shouldn't be much of a problem in practice.


 > This preprocessor would be tedious rather than difficult to write.
 >
...
 >
 > A large part of the compiler would need to be amended to cope with 
the new format, even supposing it could work with macros (which I don't 
think it could). This amendment would be uninspiring and tedious in the 
extreme.

I agree that either approach would be tedious. :-) However, a tedious 
approach that is limited to reading and byte-compilation is better than 
a tedious approach that affects all of execution.


 >> for more info, see Gemini's followup 
<https://lists.gnu.org/r/emacs-devel/2018-12/msg00043.html>.
 >
 > I've read this several times. It suffers the same drawbacks as 
Stefan's idea. In particular it doesn't give any idea how the compiler 
would operate on the proposed forms.

As I understand it, Gemini and Stefan are thinking of essentially the 
same thing: have the reader optionally generate symbols-with-positions, 
have the compiler deal with symbols-with-positions, and have the 
compiler strip positions before passing forms to macro arguments that 
are not annotated to accept positions. Although (as you mention) this 
would require amending a large part of the compiler in a tedious way, it 
should solve the problem for macro arguments that accept positions.


 >> <https://lists.gnu.org/r/emacs-devel/2018-12/msg00023.html>
 >
 > I don't think it would work, either. That idea is for macros' uses of 
eq to be replaced by BC-eq inside the macro. The trouble is, many uses 
of eq are actually expansions of EQ in the C code (e.g. in Fequal, 
Fassq, ....) and they would all need modifying too, and we're back in 
the same situation of having an alternative interpreter.

No, the idea is that the onus of doing comparisons correctly is on the 
writer of any macro annotated to understand symbols-with-positions. That 
is, it's the macro's responsibility to use appropriate comparison 
operations, and this responsibility extends to comparison operations 
like EQ that are executed in C code.

For example, I suggested that 'equal' should ignore symbol positions, as 
this would let these macros use 'equal' instead of 'eq', 'assoc' instead 
of 'assq', etc. 
<https://lists.gnu.org/r/emacs-devel/2018-12/msg00033.html>. Although 
'assoc' is written in C and its source code uses EQ, the source code 
would not need to be changed nor would it need to be compiled twice, as 
'assoc' defers to 'equal' (i.e., Fequal in C) to do the tricky work and 
'equal' would do the right thing.