[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: scratch/accurate-warning-pos: next steps.
Date: Tue, 11 Dec 2018 10:05:49 -0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1

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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]