From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: scratch/accurate-warning-pos: Solid progress: the branch now bootstraps. Date: Tue, 27 Nov 2018 17:09:15 -0500 Message-ID: References: <20181125193050.GH27152@ACM> <2c2ae483-3309-f79d-07a5-30af1f49058b@cs.ucla.edu> <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 X-Trace: blaine.gmane.org 1543356458 19640 195.159.176.226 (27 Nov 2018 22:07:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Nov 2018 22:07:38 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: michael_heerdegen@web.de, Alan Mackenzie , Eli Zaretskii , cpitclaudel@gmail.com, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 27 23:07:33 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 1gRlW0-0004zD-W0 for ged-emacs-devel@m.gmane.org; Tue, 27 Nov 2018 23:07:33 +0100 Original-Received: from localhost ([::1]:44782 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRlY7-0004Z3-EK for ged-emacs-devel@m.gmane.org; Tue, 27 Nov 2018 17:09:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58315) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRlXv-0004Yw-1Z for emacs-devel@gnu.org; Tue, 27 Nov 2018 17:09:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gRlXr-00064O-Ug for emacs-devel@gnu.org; Tue, 27 Nov 2018 17:09:31 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:52875) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRlXr-00064C-Qf; Tue, 27 Nov 2018 17:09:27 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id wARM9FrG029746; Tue, 27 Nov 2018 17:09:16 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id B8159AE5BB; Tue, 27 Nov 2018 17:09:15 -0500 (EST) In-Reply-To: <8c38f335-b25d-9ef6-110c-6efc4fda9d67@cs.ucla.edu> (Paul Eggert's message of "Tue, 27 Nov 2018 13:37:29 -0800") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6427=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6427> : inlines <6972> : streams <1805518> : uri <2756701> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:231462 Archived-At: > Hash tables for cons locations would work well enough, if someone had the > time to put into it. Experiment with this approach seemed to indicate that it would slowdown compilation tremendously (not just a few percents) because of the cost of all those hash table operations. > 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 agree that making modifications to the byte-compiler is fundamentally what we want to do. My current thinking is that we could try to do something like the following: `read-with-positions` could return annotated-sexps that would look like: (locinfo FILE POS (foo (locinfo FILE POS a) (locinfo FILE POS 4))) for an input like (foo a 4) It would significantly increase the size of the sexp and hence incur a slowdown, but it won't be nearly as bad as with the hash-table hack. Preservation of this info through the byte-compiler itself wouldn't take too much effort (most of the code can treat `locinfo` as a kind of function which returns its 3 argument). The main problem is for macro expansion: when we call a macro we can't pass it these annotated sexps, so we have to de-annotate the sexp arguments, which is both extra work and a loss of important info. So I was thinking of reducing the pain by re-using the edebug info so as to find those arguments (or parts of arguments) which are treated as normal expressions, which we don't need to de-annotate. FWIW, these are just idle thoughts. I don't really have the intention to work on it in the foreseeable future. Stefan