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: Solid progress: the branch now bootstraps. Date: Tue, 27 Nov 2018 21:53:47 +0000 Message-ID: <20181127215347.GC4705@ACM> References: <20181125212920.GK27152@ACM> <60ac9dfc-b540-89f9-68ea-ec7cceaa8511@cs.ucla.edu> <83in0kijz0.fsf@gnu.org> <9e216e61-7d95-94f0-cbee-593b4f32ced2@cs.ucla.edu> <20181126184359.GG4030@ACM> <55044caa-18fb-9e9a-81b4-3912f64d0aa4@cs.ucla.edu> <20181127074336.GA4705@ACM> <0ec5806a-0cc6-8b9f-6bc2-97875e36a511@cs.ucla.edu> <20181127211539.GB4705@ACM> <8c38f335-b25d-9ef6-110c-6efc4fda9d67@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1543355724 26977 195.159.176.226 (27 Nov 2018 21:55:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Nov 2018 21:55:24 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: michael_heerdegen@web.de, Eli Zaretskii , emacs-devel@gnu.org, cpitclaudel@gmail.com, monnier@IRO.UMontreal.CA To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 27 22:55:19 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 1gRlK8-0006r3-QQ for ged-emacs-devel@m.gmane.org; Tue, 27 Nov 2018 22:55:16 +0100 Original-Received: from localhost ([::1]:44741 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRlMF-0006SK-Aa for ged-emacs-devel@m.gmane.org; Tue, 27 Nov 2018 16:57:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54807) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRlM9-0006SE-Av for emacs-devel@gnu.org; Tue, 27 Nov 2018 16:57:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gRlM5-0007p1-P1 for emacs-devel@gnu.org; Tue, 27 Nov 2018 16:57:21 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:10607 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gRlM4-0007oS-Kb for emacs-devel@gnu.org; Tue, 27 Nov 2018 16:57:17 -0500 Original-Received: (qmail 62207 invoked by uid 3782); 27 Nov 2018 21:57:15 -0000 Original-Received: from acm.muc.de (p2E5D5B5F.dip0.t-ipconnect.de [46.93.91.95]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 27 Nov 2018 22:57:12 +0100 Original-Received: (qmail 30489 invoked by uid 1000); 27 Nov 2018 21:53:47 -0000 Content-Disposition: inline In-Reply-To: <8c38f335-b25d-9ef6-110c-6efc4fda9d67@cs.ucla.edu> 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:231461 Archived-At: Hello, Paul. On Tue, Nov 27, 2018 at 13:37:29 -0800, Paul Eggert wrote: > On 11/27/18 1:15 PM, Alan Mackenzie wrote: > > Anyhow, as far as creating a better solution than > > scratch/accurate-warning-pos goes, have you had any further thoughts? > Hash tables for cons locations would work well enough, if someone had > the time to put into it. I don't think they would. Macros would mess things up. For example, after expanding a macro like the contrived (defmacro dehash (form) (copy-tree form)) , how would the recorded cons locations be linked up with the resulting form? > The main objection seems to be that the byte-compiler would lose track > of location information. But we can fix the byte-compiler so that it > doesn't lose track of the location information. That's purely a > byte-compiler issue, which is a good thing for software engineering > reasons as well as for performance reasons. I don't think this is right. See above. > > I've thought about the double interpreter idea, and must confess I've no > > idea how one might go about implementing it in any reasonable time. > There's a simpler way to do a double interpreter. Use a compile-time > test to decide whether eq operates slowly. Build two copies of Emacs, > the slow one and the fast one, by compiling the slow one with -DSLOW_EQ > (or whatever). Use the slow Emacs to byte-compile Emacs (and any other > program that wants to be byte-compiled); this will output nicer > diagnostics. Use the fast Emacs for everything else. > I'm not saying I *like* this solution (I don't). But it would address > the problem of poor diagnostic locations when building Emacs, and it > shouldn't slow Emacs down one bit in ordinary use. Of course, the "slow" Emacs would somehow need to be used by the byte compiler after Emacs has been built, to continue to get accurate warning locations. I don't like this approach either. ;-) -- Alan Mackenzie (Nuremberg, Germany).