[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.
- Re: scratch/accurate-warning-pos: next steps., (continued)
- Re: scratch/accurate-warning-pos: next steps., Alan Mackenzie, 2018/12/10
- Re: scratch/accurate-warning-pos: next steps., Eli Zaretskii, 2018/12/10
- Re: scratch/accurate-warning-pos: next steps., Alan Mackenzie, 2018/12/10
- Re: scratch/accurate-warning-pos: next steps., Eli Zaretskii, 2018/12/10
- Re: scratch/accurate-warning-pos: next steps., Alan Mackenzie, 2018/12/10
- Re: scratch/accurate-warning-pos: next steps., Eli Zaretskii, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps., Stefan Monnier, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps., Stefan Monnier, 2018/12/11
Re: scratch/accurate-warning-pos: next steps., Paul Eggert, 2018/12/10
- Re: scratch/accurate-warning-pos: next steps., Alan Mackenzie, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps.,
Paul Eggert <=
- Re: scratch/accurate-warning-pos: next steps., Alan Mackenzie, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps., Paul Eggert, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps., Alan Mackenzie, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps., Stefan Monnier, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps., Alan Mackenzie, 2018/12/11
- Re: scratch/accurate-warning-pos: next steps., Stefan Monnier, 2018/12/11
Re: scratch/accurate-warning-pos: next steps., Paul Eggert, 2018/12/11