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: Mon, 10 Dec 2018 21:03:10 +0000 Message-ID: <20181210210310.GF4188@ACM> References: <20181210180033.GC4188@ACM> <831s6p2qq1.fsf@gnu.org> <20181210182830.GD4188@ACM> <83zhtd1b0j.fsf@gnu.org> <20181210193557.GE4188@ACM> <83y38x1706.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1544476036 15256 195.159.176.226 (10 Dec 2018 21:07:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 10 Dec 2018 21:07:16 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 10 22:07:12 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 1gWSlj-0003rM-5C for ged-emacs-devel@m.gmane.org; Mon, 10 Dec 2018 22:07:11 +0100 Original-Received: from localhost ([::1]:34766 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWSnp-00078O-LQ for ged-emacs-devel@m.gmane.org; Mon, 10 Dec 2018 16:09:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWSn3-000788-58 for emacs-devel@gnu.org; Mon, 10 Dec 2018 16:08:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWSmz-0004C3-FD for emacs-devel@gnu.org; Mon, 10 Dec 2018 16:08:32 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:11176 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gWSmw-00047L-82 for emacs-devel@gnu.org; Mon, 10 Dec 2018 16:08:27 -0500 Original-Received: (qmail 47950 invoked by uid 3782); 10 Dec 2018 21:08:24 -0000 Original-Received: from acm.muc.de (p2E5D5AF9.dip0.t-ipconnect.de [46.93.90.249]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 10 Dec 2018 22:08:23 +0100 Original-Received: (qmail 9976 invoked by uid 1000); 10 Dec 2018 21:03:10 -0000 Content-Disposition: inline In-Reply-To: <83y38x1706.fsf@gnu.org> 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:231748 Archived-At: Hello, Eli. On Mon, Dec 10, 2018 at 22:06:33 +0200, Eli Zaretskii wrote: > > Date: Mon, 10 Dec 2018 19:35:57 +0000 > > Cc: emacs-devel@gnu.org > > From: Alan Mackenzie > > > Then how about invoking this alternative interpreter only if the prime > > > interpreter detected a warning or error while byte-compiling? You > > > could invoke the alternative interpreter only on the form where the > > > problem was detected, with the goal of "drilling down" to find the > > > exact position of the problematic symbol(s). > > That would mean starting the byte compilation with no position > > information being gathered, and then when an warning occurs, aborting > > the compilation and starting again from scratch with the position > > information being gather and alternative interpreter being used. > Not necessarily. It could mean invocation of a special code whose > goal is to find the position of an error in a given form. The > position of the beginning of this form will have been known, as AFAIU > the existing byte compiler does collect that, or has means to > determine that. We know the position of the beginning of the form, yes. We need some way of determining the source position of a symbol, cons, or vector on the inside of this form. The traditional alist of symbols and positions is one way, and it no longer works well (if it ever did). Symbols with position is another way, which appears to work well, in spite of the complexity. You seem to be proposing a third way, but without giving away any details. > > The problem is, that we cannot use # in the normal > > interpreter, since it is not EQ nil there. > I'm not sure you must use symbols with positions in the above > arrangement, you could simply invoke special-purpose code that > analyzed the problematic form. But if you do need to use symbols with > positions, you could do this only when looking for error position, so > other symbol comparisons will not be affected. I'm not sure how this special-purpose code would work. Say we find an error or warning involving symbol foo as the car of some form, I can't see any way of determining its source position that doesn't involve going back to the position of the beginning of the form, and slogging through the form, somehow. Maybe, rather than reading the form, we could scan it a token at a time, storing it in, say vectors, rather like a traditional non-lisp compiler does. But this is hardly attractive, and would be a LOT of work. > > I understand the idea, yes. But given the timings I measured in the > > existing scratch/accurate-warning-pos (IIRC, around 11% - 12% for an > > actual compilation) and the fact that in the alternative interpreter, > > the slowdown will be somewhat less (one fewer flag comparison per EQ, > > NILP, ...., and we can drop the traditional alist of symbols and > > positions which is running alongside the new symbols with position) it > > may not be worth the extra complexity. > Yes, but what you suggested as the implementation of the alternative > interpreter includes a heck of complexity of its own, IMO. It does, yes. Partly imposed by external circumstances. ;-) > The idea I proposed doesn't even require changes in basic types, it > could hopefully be implemented with "normal" Lisp. The symbols with positions idea doesn't conceptually change basic types either - it just adds annotations to an existing type. Anything you could do with symbols before, you can still do with symbols-with-positions and get the same answers now. If you have come up with a new way of getting a source position for a symbol or a cons, please detail it here. I recognise the complexity in what I'm proposing and what I've already implemented, and I don't think it's good; it's just less bad than anything else that's come up, so far. -- Alan Mackenzie (Nuremberg, Germany).