From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: next steps. Date: Tue, 11 Dec 2018 10:05:49 -0800 Organization: UCLA Computer Science Department Message-ID: References: <20181210180033.GC4188@ACM> <20181211113420.GB4911@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1544554633 13115 195.159.176.226 (11 Dec 2018 18:57:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2018 18:57:13 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 11 19:57:09 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 1gWnDQ-0003Ib-Rh for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 19:57:09 +0100 Original-Received: from localhost ([::1]:40963 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWnFX-0001tG-IK for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 13:59:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWmQF-0000nn-Nz for emacs-devel@gnu.org; Tue, 11 Dec 2018 13:06:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWmQA-0008O3-PE for emacs-devel@gnu.org; Tue, 11 Dec 2018 13:06:19 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:35878) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gWmQA-0008Dz-EX for emacs-devel@gnu.org; Tue, 11 Dec 2018 13:06:14 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 180091608C1; Tue, 11 Dec 2018 10:05:53 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id H42p79bMJdVA; Tue, 11 Dec 2018 10:05:51 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id CC8EF1608B8; Tue, 11 Dec 2018 10:05:51 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id EsyALzPC_GXm; Tue, 11 Dec 2018 10:05:51 -0800 (PST) Original-Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id B1A3D1608B7; Tue, 11 Dec 2018 10:05:51 -0800 (PST) Openpgp: preference=signencrypt Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBfgQTAQIAKAUCTIByZAIbAwUJEswDAAYLCQgHAwIG FQgCCQoLBBYCAwECH In-Reply-To: <20181211113420.GB4911@ACM> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 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:231755 Archived-At: 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 . > > 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. >> > > 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. . 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.