From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: next steps. Date: Tue, 11 Dec 2018 19:20:01 +0000 Message-ID: <20181211192001.GC4911@ACM> References: <20181210180033.GC4188@ACM> <20181211113420.GB4911@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1544556208 1310 195.159.176.226 (11 Dec 2018 19:23:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2018 19:23:28 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 11 20:23:24 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gWncq-0000Fz-D8 for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 20:23:24 +0100 Original-Received: from localhost ([::1]:41121 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWnex-0005Jr-6p for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 14:25:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43318) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWnep-0005JM-13 for emacs-devel@gnu.org; Tue, 11 Dec 2018 14:25:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWnel-0003EA-PA for emacs-devel@gnu.org; Tue, 11 Dec 2018 14:25:26 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:53396 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gWnel-0003Ch-Ek for emacs-devel@gnu.org; Tue, 11 Dec 2018 14:25:23 -0500 Original-Received: (qmail 36844 invoked by uid 3782); 11 Dec 2018 19:25:21 -0000 Original-Received: from acm.muc.de (p2E5D5A02.dip0.t-ipconnect.de [46.93.90.2]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 11 Dec 2018 20:25:20 +0100 Original-Received: (qmail 8896 invoked by uid 1000); 11 Dec 2018 19:20:01 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:231758 Archived-At: Hello, Paul. On Tue, Dec 11, 2018 at 10:05:49 -0800, Paul Eggert wrote: > 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? I don't know, at this stage. Probably not. > If so, aren't we limiting builds to platforms that have binutils, > which would be a new restriction? Well, we use ld, which also belongs to binutils, and that doesn't seem to restrict the platforms. Other platforms surely have equivalents to both objdump and ld, and they are/would be used appropriately. > 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. globals.h seems to manage. The objdump output could be generated analogously. Somehow. Probably. > >> .... 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. Possibly not. The same would have to be done with file global data, too. But doing it that way would involve a great deal of change to the source code (testing for the -D option) which would not be popular. > > 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. It would likely slow down the compilation by a very great deal. > > 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. :-) No. You're conflating "tedious" with "tedious in the extreme". They're different. The first is several days of work. The second is many weeks of work. I tried an approach two years ago which involved amending most of the compiler. Although spending a fair amount of time on it, I didn't get very far, and gave up. Were the reader to produce "Stefan's form", the work to amend the compiler would be more even than what I gave up on. > However, a tedious approach that is limited to reading and > byte-compilation is better than a tedious approach that affects all of > execution. My proposed approach would affect only byte compilation (and the build process, of course). That's the whole point. Besides, my approach will work. The competing half-baked ideas are not even fully formulated, and likely wouldn't work. > >> for more info, see Gemini's followup > >> . > > 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. This would place onerous restrictions on what macros were allowed to do, and likely be incompatible with a vast proportion of existing macros. > >> > > 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. I think that is an unacceptable change in Emacs. Macros are already difficult enough to write. Such restrictions could make macros impossible, except for "experts". Besides, we want to maintain compatibility with the vast body of existing macros. > 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. > . 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. The trouble is, macros DO use eq. And why not? The contortions you're envisaging contrast horribly with the simplicity of scratch/accurate-warning-pos, which simply works. It works because it has not changed any of the basic types or interactions between them. -- Alan Mackenzie (Nuremberg, Germany).