From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Correct line/column numbers in byte compiler messages [Was: GNU is looking for Google Summer of Code Projects] Date: Fri, 20 Mar 2020 20:10:05 +0000 Message-ID: <20200320201005.GC5255@ACM> References: <20200319203449.GA4180@ACM> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="104533"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Rocky Bernstein , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Mar 20 21:10:50 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jFNyk-000R5q-47 for ged-emacs-devel@m.gmane-mx.org; Fri, 20 Mar 2020 21:10:50 +0100 Original-Received: from localhost ([::1]:58742 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jFNyj-0003nL-6o for ged-emacs-devel@m.gmane-mx.org; Fri, 20 Mar 2020 16:10:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34974) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jFNy7-0003HV-5Q for emacs-devel@gnu.org; Fri, 20 Mar 2020 16:10:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jFNy5-0002oM-Sb for emacs-devel@gnu.org; Fri, 20 Mar 2020 16:10:11 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:52354 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1jFNy5-0002mu-Iy for emacs-devel@gnu.org; Fri, 20 Mar 2020 16:10:09 -0400 Original-Received: (qmail 37270 invoked by uid 3782); 20 Mar 2020 20:10:08 -0000 Original-Received: from acm.muc.de (p4FE15C8D.dip0.t-ipconnect.de [79.225.92.141]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 20 Mar 2020 21:10:05 +0100 Original-Received: (qmail 5291 invoked by uid 1000); 20 Mar 2020 20:10:05 -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.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:245611 Archived-At: Hello, Stefan. On Thu, Mar 19, 2020 at 17:41:30 -0400, Stefan Monnier wrote: > > things like cconv.el here). More to the point, users' macros chew up and > > spit out cons cells, and we have no control over them. So whilst we > > could, with a lot of tedious effort, clean up our own software to > > preserve cons cells (believe me, I've tried), this would fail in users' > > macros. > I think fat-cons cells are cheap to implement (with (hopefully) no > performance impact when not used ..... They may be cheap to implement in themselves, but adapting the entire byte compiler and all our macros to the heavily restricted semantics they would impose would be an enormous job. I've tried something similar, and gave up in exhaustion. > or weird semantic artifacts like the fat-symbol approach you tried), Er, not "tried" but "implemented", please. The implementation was complete, and was capable of bootstrapping Emacs with correct positions for all the (then plentiful) warning messages. > and can work 99.9% right in the long term with an incremental way to > get there. Where does this 99.9% come from? How is this cons tracking you're proposing supposed to work, when there are an infinite number of occurrences of the likes of (cons (car form) (cdr form)) in our code? > Furthermore it matches the "usual" way to deal with this problem, so > there's very little doubt about whether it can work or not. Are you saying that this is how other Lisp compilers deal with source code positions? How do they deal with the difficult problem of user macros? Could you give me an example of a free Lisp system which works this way? I'd be interested in having a look at it. I think there's quite a bit of doubt as to whether this could work effectively in Emacs. The way to dispel this doubt is for Somebody (tm) to implement it. > > Since then I've worked a fair bit on creating a "double" Emacs core, > > one core being for normal use, the other for byte compiling. > > There's a fair amount of work still to do on this, but I know how to > > do it. The problem is that I have been discouraged by the prospect > > of having this solution vetoed too, since it will make Emacs quite a > > bit bigger. > I'd probably try to veto it, indeed. It might be a good solution in > the short-term but it'd just slow down our progress in the long term. Fixing bugs slows down our progress? To which the answer is to install the working solution pending the implementation of something better, after which it can be superseded. Somehow, even that strategy tends to get vetoed. > Stefan -- Alan Mackenzie (Nuremberg, Germany).