From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: next steps. Date: Tue, 11 Dec 2018 08:41:00 +0200 Message-ID: <83lg4w1s77.fsf@gnu.org> References: <20181210180033.GC4188@ACM> <831s6p2qq1.fsf@gnu.org> <20181210182830.GD4188@ACM> <83zhtd1b0j.fsf@gnu.org> <20181210193557.GE4188@ACM> <83y38x1706.fsf@gnu.org> <20181210210310.GF4188@ACM> NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1544510368 19093 195.159.176.226 (11 Dec 2018 06:39:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 11 Dec 2018 06:39:28 +0000 (UTC) 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 07:39: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 1gWbhU-0004sv-Bu for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 07:39:24 +0100 Original-Received: from localhost ([::1]:36237 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWbja-0002Bj-OP for ged-emacs-devel@m.gmane.org; Tue, 11 Dec 2018 01:41:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47769) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWbjO-0002Be-Q1 for emacs-devel@gnu.org; Tue, 11 Dec 2018 01:41:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWbjJ-0000i8-Lp for emacs-devel@gnu.org; Tue, 11 Dec 2018 01:41:21 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56188) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWbjC-0000fw-KI; Tue, 11 Dec 2018 01:41:11 -0500 Original-Received: from [176.228.60.248] (port=2985 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1gWbjC-0005WW-7Q; Tue, 11 Dec 2018 01:41:10 -0500 In-reply-to: <20181210210310.GF4188@ACM> (message from Alan Mackenzie on Mon, 10 Dec 2018 21:03:10 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:231752 Archived-At: > Date: Mon, 10 Dec 2018 21:03:10 +0000 > Cc: emacs-devel@gnu.org > From: Alan Mackenzie > > > > 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. I don't have any details, just an idea. I hope it could be helpful, because implementing it would side-step all the problems you discovered with the other approaches: . it doesn't slow down the Lisp interpreter . it doesn't slow down byte compilation when there are no errors/warnings to report . it probably doesn't require introduction of new low-level facilities, like annotating symbols with positions or redirecting Lisp subroutines to alternative versions > 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. Yes, I was proposing something like that. Why is that a problem? > 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'm not sure why is it less attractive than the other alternatives. But if my idea doesn't sound helpful, feel free to disregard it.