From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: Comparing symbol-with-position using eq Date: Fri, 5 Apr 2019 18:21:06 +0000 Message-ID: <20190405182106.GC4208@ACM> References: <20190402112537.GA6212@ACM> <20190402202412.GA25792@ACM> <4a2df4442b4acf2eb2dabd3c2c4227c5.squirrel@dancol.org> <20190402210013.GD25792@ACM> <87bm1l6oq5.fsf@gmail.com> <20190405082652.GA4208@ACM> <87ftqwcrgo.fsf_-_@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="133604"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Daniel Colascione , emacs-devel@gnu.org To: Alex Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 05 21:22:55 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hCUQQ-000YRd-70 for ged-emacs-devel@m.gmane.org; Fri, 05 Apr 2019 21:22:54 +0200 Original-Received: from localhost ([127.0.0.1]:45955 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hCUQP-0003Lv-3U for ged-emacs-devel@m.gmane.org; Fri, 05 Apr 2019 15:22:53 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34806) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hCUPn-0003Lq-GS for emacs-devel@gnu.org; Fri, 05 Apr 2019 15:22:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hCUPl-0000gv-GN for emacs-devel@gnu.org; Fri, 05 Apr 2019 15:22:15 -0400 Original-Received: from colin.muc.de ([193.149.48.1]:22978 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1hCUOp-0007US-8k for emacs-devel@gnu.org; Fri, 05 Apr 2019 15:22:12 -0400 Original-Received: (qmail 51696 invoked by uid 3782); 5 Apr 2019 18:21:07 -0000 Original-Received: from acm.muc.de (p4FE15E79.dip0.t-ipconnect.de [79.225.94.121]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 05 Apr 2019 20:21:06 +0200 Original-Received: (qmail 15035 invoked by uid 1000); 5 Apr 2019 18:21:06 -0000 Content-Disposition: inline In-Reply-To: <87ftqwcrgo.fsf_-_@gmail.com> 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:235000 Archived-At: Hello, Alex. On Fri, Apr 05, 2019 at 11:05:59 -0600, Alex wrote: > Hello, Alan. > Alan Mackenzie writes: > > On Thu, Apr 04, 2019 at 22:49:22 -0600, Alex wrote: > >> I apologize if this topic already reached its conclusion, but IMO > >> having eq return true for two different object types is quite > >> surprising behaviour. > > We are comparing two symbols, both of which are 'foo, but one of which is > > annotated with its position in a source file. The two symbols are the > > same symbol. > Is it not comparing a symbol with a pseudovector containing that symbol > and a position? At the machine code level, that is what it's doing, yes. > > I understand the reaction to the idea, though. Even though the > > representation of these two objects is different, conceptually they are > > the same object. > Similar objects, but I don't believe that's enough for eq. Consider that > it's regarded non-portable in Lisp to compare integers with eq since the > same number may be represented by different objects, or (eq 3 3.0), or > (eq (list 1 2) (list 1 2)). The point is that comparing 'foo with (Symbol "foo" at 339) with `eq', and returning t doesn't do any harm. On the contrary, it enables correct source positions to be output in byte compiler warning messages. That it does no harm is verified by the fact that a make bootstrap with such annotated symbols works. However, there is a slight slowdown in this Emacs, compared with the master branch. The powers that be have intimated that this slowdown is unacceptable, so I'm having to make more far reaching changes in the C code to confine this slowdown to byte compilation. > > But consider: on a make bootstrap I did last night, there were 332 > > warning messages from the byte compiler. Of these, only 80 gave the > > correct line/column position, the other 252 being wrong. There have been > > several bug reports from users complaining about such false positions. > > This is what I'm trying to fix. > I agree that it's a problem very much worth fixing; thank you for > working on it. It's a difficult problem. The idea of annotating symbols with a source position (this was Stefan M.'s idea) is the only idea which has even come close to solving this problem. I was struggling with another approach back in 2016 which involved keeping the source location in a hash table indexed by the corresponding cons cell. This effort collapsed from the sheer tedium of the changes needed, coupled with the unlikelihood of getting the changes working, to say nothing of the fact it would have rendered the byte compiler unreadable. > >> Is it out of the question to leave eq alone and introduce, e.g., > >> eq-excluding-position that strips possible positions before comparison? > > It is, rather. To implement this would involve rewriting everything > > which calls eq and is used by the byte compiler, to call > > eq-excluding-position instead. These functions would need to exist in > > two versions. There are rather a lot of functions which use eq. ;-) > Why would you need to rewrite the helper procedures that the byte > compiler uses? What about stripping the position at each relevant call > site? I'm not sure what you mean here. If by "relevant call site" you mean "places where `eq' is used", there are just too many of them. They're in the C code as well as the Lisp. If you mean "places where the helper procedures are called", then that stripping the positions would negate the whole point of the symbols with positions, since it is these helper procedures which output warning messages. Or did you mean something else? -- Alan Mackenzie (Nuremberg, Germany).