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: Thoughts on getting correct line numbers in the byte compiler's warning messages Date: Tue, 6 Nov 2018 15:11:43 +0000 Message-ID: <20181106151143.GB4030@ACM> References: <20181101175953.GC4504@ACM> <20181105105302.GA10520@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1541517054 11749 195.159.176.226 (6 Nov 2018 15:10:54 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 6 Nov 2018 15:10:54 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 06 16:10:49 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 1gK30C-0002uz-Uq for ged-emacs-devel@m.gmane.org; Tue, 06 Nov 2018 16:10:49 +0100 Original-Received: from localhost ([::1]:41588 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gK32I-0001t7-UT for ged-emacs-devel@m.gmane.org; Tue, 06 Nov 2018 10:12:58 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34948) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gK328-0001su-ST for emacs-devel@gnu.org; Tue, 06 Nov 2018 10:12:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gK324-0002VA-Rs for emacs-devel@gnu.org; Tue, 06 Nov 2018 10:12:48 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:46685 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gK322-0002Go-TI for emacs-devel@gnu.org; Tue, 06 Nov 2018 10:12:44 -0500 Original-Received: (qmail 92940 invoked by uid 3782); 6 Nov 2018 15:12:37 -0000 Original-Received: from acm.muc.de (p5B14799F.dip0.t-ipconnect.de [91.20.121.159]) by colin.muc.de (tmda-ofmipd) with ESMTP; Tue, 06 Nov 2018 16:12:36 +0100 Original-Received: (qmail 19927 invoked by uid 1000); 6 Nov 2018 15:11:43 -0000 Content-Disposition: inline In-Reply-To: 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:231041 Archived-At: Hello, Stefan. On Tue, Nov 06, 2018 at 08:56:48 -0500, Stefan Monnier wrote: > > Actually this idea was not good; > [ I'll assume you're not talking about the idea of using such a reader in > edebug, but about using such a reader for your use case. ] In particular, in the byte compiler. > > macros could not handle such a form without severe changes in the way > > macros work. (A research project, perhaps). > Right. The way I was thinking about it was that when calling > macros we'd do something like: > (plain-to-annotated > (macroexpand (annotated-to-plain sexp))) That would lose too much of the wanted source position data. > not a research project by any stretch, but its impact on performance > could be a problem, indeed. > > The reader would produce, in place of the Lisp_Objects it currently > > does, an object with Lisp_Type 1 (which is currently unused). The rest > > of the object would be an address pointing at two Lisp_Objects, one > > being the "real" read object, the other being a source position. > More generally, you're suggesting here to add a new object type (could > just as well be a new pseudo-vector or any such thing: these are just > low-level concerns that don't really affect the overall design). There's nothing just about hurting performance. > > The low level routines, like CONSP, and a million others in lisp.h would > > need amendment. > So you're suggesting to change the low-level routines accessing > virtually all object types to also accept those "annotated objects"? Yes. > That means all processing of all objects would be slowed down. > I think that's a serious problem (I'd rather pay a significant slow > down in byte-compilation than a smaller slowdown on everything else). The slow down would not be great. For example, XCONS first checks the 3-bit tag, and if all's OK, removes it, otherwise it handles the error. I'm proposing enhancing the "otherwise" to check for a tag of 1 together with a proper cons at the far end of a pointer. With care, there should be no loss in the usual case, here. I timed a bootstrap, unoptimised GCC, with an extra tag check and storage to a global variable inserted into XFIXNUM. (Currently there is no such check there). The slowdown was around 1.3% > > But the Lisp system would continue with 8-byte objects, > > and the higher level bits (nearly all of it) would not need changes. > > The beauty of this scheme is that, outside of byte compilation, nothing > > else would change. > Also, I wonder how this (or any other of the techniques discussed) solve > the original problem you describe: > The forms created by the reader go through several (?many) > transformative phases where they get replaced by successor forms. > This makes things more difficult. Many of the original forms produced by the reader survive these transformations. For those that do not, we could bind byte-compile-containing-position (or whatever) to a sensible position each time the compiler enters a "major" form (whatever that might mean). > E.g. we could implement big-object as > 1. (defun big-object (object location) > (cons object location)) > or > 2. (defun big-object (object location) > (puthash object location location-hash-table) > object) > or > 3. (defun big-object (object location) > (make-new-special-object object location)) 1. wouldn't work, as such. E.g. evaluating `car' must get the car of the original OBJECT, not the car of (cons OBJECT LOCATION). I've tried 2., and given up on it: everywhere in the compiler where FORM is transformed to NEWFORM, a copy of a hash has to be created for NEWFORM. Also, there's no convenient key for recording the hash of an occurence of a symbol (such as `if'). 3. is what I'm proposing, I think. The motivating thing here is that the rest of the system can handle NEW-SPECIAL-OBJECT and get the same result it would have from OBJECT. Hence the use of Lisp_Type 1, or possibly a new pseudovector type. > but the problem remains of how to put it at all the places where we > need it. Every object produced by the reader during byte compilation would have its source position attached to the object, in essence. Objects produced by macro expansion would not have this, but we could arrange to copy the info much of the time. (E.g. the result of a `mapcar' operating on a list of FORMs would be given the position information of the list.) Other non-reader forms would have to depend on the variable byte-compile-containing-position mentioned above. Incidentally, I'm coming round the the idea of calling the new object an _extended_ object. In place of the fixnum source position proposed, we could use, for example, a property list. There are surely many applications for having a property list on a cons form. :-) > > The extra indirection involved in these "big objects" would naturally > > slow down byte compilation somewhat. I've no idea how much, but it > > might not be much at all. > Indeed, I don't think that's a significant issue. > Stefan -- Alan Mackenzie (Nuremberg, Germany).