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: Solid progress: the branch now bootstraps. Date: Wed, 28 Nov 2018 12:04:43 +0000 Message-ID: <20181128120443.GA4036@ACM> References: <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> <20181127215347.GC4705@ACM> <23334086-c0a1-7b34-4234-343719618bd1@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1543407629 29463 195.159.176.226 (28 Nov 2018 12:20:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Nov 2018 12:20:29 +0000 (UTC) User-Agent: Mutt/1.10.1 (2018-07-13) Cc: michael_heerdegen@web.de, Eli Zaretskii , emacs-devel@gnu.org, cpitclaudel@gmail.com, monnier@IRO.UMontreal.CA To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 28 13:20: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 1gRypL-0007XP-Kr for ged-emacs-devel@m.gmane.org; Wed, 28 Nov 2018 13:20:23 +0100 Original-Received: from localhost ([::1]:47367 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRyrS-0007pn-5O for ged-emacs-devel@m.gmane.org; Wed, 28 Nov 2018 07:22:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58819) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gRyq6-0006JY-ON for emacs-devel@gnu.org; Wed, 28 Nov 2018 07:21:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gRydh-0006fX-MU for emacs-devel@gnu.org; Wed, 28 Nov 2018 07:08:28 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:31222 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1gRydh-0006dz-6V for emacs-devel@gnu.org; Wed, 28 Nov 2018 07:08:21 -0500 Original-Received: (qmail 82844 invoked by uid 3782); 28 Nov 2018 12:08:18 -0000 Original-Received: from acm.muc.de (p2E5D5BA9.dip0.t-ipconnect.de [46.93.91.169]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 28 Nov 2018 13:08:16 +0100 Original-Received: (qmail 4873 invoked by uid 1000); 28 Nov 2018 12:04:43 -0000 Content-Disposition: inline In-Reply-To: <23334086-c0a1-7b34-4234-343719618bd1@cs.ucla.edu> 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:231485 Archived-At: Hello, Paul On Tue, Nov 27, 2018 at 17:11:48 -0800, Paul Eggert wrote: > On 11/27/18 1:53 PM, Alan Mackenzie wrote: > > Macros would mess things up. For example, after expanding a macro like > > the contrived > > (defmacro dehash (form) > > (copy-tree form)) > > , how would the recorded cons locations be linked up with the resulting > > form? > People typically don't write macros like that, .... For the pertinent value of "like", they do. The essential feature of that macro is that it returns a list form whose conses are not the input conses. In a typical macro, only some of the conses survive the processing. For example, every time the macro result is something like: `(progn ,@(mapcar 'foo body)) , the conses in the return list are new, and the old conses are lost. Look at cconv-closure-convert. I know this isn't, strictly speaking, a macro, but it rearranges code the way macros do. In its output there isn't a single cons which was present in the input. > .... so we needn't tune our design for it. It's not a matter of "tuning" the design. It's a matter of having a scheme which will work at all. > .... More commonly, people write macros containing errors, such as: >   (defmacro face-attribute-specified-or (value default &rest body) >     (let ((temp (make-symbol "value"))) >       `(or >          (let ((,temp ,value)) >            (if (eq ,temp 'unspecified) >                (progn ,@body) >              default)) >          ,temp))) > This has a parenthesization typo and the macro doesn't mean what the > user probably intended. For these macros, as I understand it the > symbols-with-pos approach messes up because the symbol associated with > the error was built by make-symbol and doesn't have a source code > position. It doesn't "mess up". It's that the compiler isn't designed to give warning messages about already compiled macros being used, and this is the case regardless of whether symbols-with-pos or conses-with-pos is used. To change this is a separate question which we should deal with separately, if at all. > In contrast, the cons-with-pos approach should return a good location > in the macro itself for the undeclared symbol (i.e., just before the > last ",temp"). No. Assuming the macro is compiled, just where are these cons positions going to be stored? Byte compiled functions/macros don't consist of conses. Merely evaluated functions/macros do consist of conses, but they also consist of symbols, so ons-with-pos doesn't come out ahead, here. Anyhow, this is all a diversion from the main point, which is how to generate warning positions for the source currently being compiled. > One can also come up with examples where the symbols-with-pos approach > is better than the cons-with-pos approach. That is, neither approach > dominates the other. You're wrong, here. Symbols-with-pos works on the output from macros. Conses-with-pos will only do so for some "nice" macros, ones which preserve their input conses. > So, which approach would be better in practice? I don't think we know. Well, in practice, the symbols-with-pos approach exists and works, even if it is currently unfinished. cons-with-pos has been tried, by me, and never reached anything like a working version. I'm convinced the idea can't work. Maybe it needs somebody more capable than me to implement cons-with-pos. ######################################################################### > > the "slow" Emacs would somehow need to be used by the byte compiler > > after Emacs has been built, to continue to get accurate warning locations. > That's easy enough: the fast Emacs can fork and exec the slow one, which > can be installed next to movemail etc. (Again, not that I like this > approach.) Thinking about it, what other approach is there? Because of the ~6728 macro calls of EQ, NILP, .... scattered throughout the Emacs sources, almost all that source will need to be compiled twice, and one way or another be made available to users in two forms. -- Alan Mackenzie (Nuremberg, Germany).