From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Daniel Colascione" Newsgroups: gmane.emacs.devel Subject: Re: Comparing symbol-with-position using eq Date: Fri, 5 Apr 2019 13:18:55 -0700 Message-ID: <47d94f87b51706205f4fe7ce4d938d53.squirrel@dancol.org> 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> <20190405182106.GC4208@ACM> Mime-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="4780"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: SquirrelMail/1.4.23 [SVN] Cc: Daniel Colascione , Alex , emacs-devel@gnu.org To: "Alan Mackenzie" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 05 22:52:30 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 1hCVp6-00014V-IT for ged-emacs-devel@m.gmane.org; Fri, 05 Apr 2019 22:52:29 +0200 Original-Received: from localhost ([127.0.0.1]:46758 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hCVp5-0004cK-JS for ged-emacs-devel@m.gmane.org; Fri, 05 Apr 2019 16:52:27 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40442) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hCVoz-0004cC-Sn for emacs-devel@gnu.org; Fri, 05 Apr 2019 16:52:23 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hCVor-0001c1-PP for emacs-devel@gnu.org; Fri, 05 Apr 2019 16:52:18 -0400 Original-Received: from dancol.org ([2600:3c01::f03c:91ff:fedf:adf3]:50904) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hCVoh-00014W-KL for emacs-devel@gnu.org; Fri, 05 Apr 2019 16:52:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Cc:To:From:Subject:Date:References:In-Reply-To:Message-ID; bh=PZKEknfgnV89LDI6JBpXnlpkJ+17NL4x3FD08MOMeew=; b=dr/epdnt/UROFCvV3NfUq5Kjh/e9xWH6vEPPs+v3gmLcmcPui1uXHVtBl5L+73q6A73P54OZazkCPoIMk8tS7NW4wfBoh4JRSL9O5FdLxOqaGH59afHfCsk3xnv0dorGIRo0JOLGmVzW25gQZOROSgi4/vtfCKkrLjvUH/Qn8tLTQ0LBN8KNyccDTWC6t3gUeXrTlk+V/xy2XB/qxOt8squ+TfFu93O++325yaFJlYYF2bOs2PdhRNgpno6AKkGfwtDK6MxMSviAnFWhMBfnNSH/vdeBAINDURzmu3WhpCN2tb16PcgTcfr8rw0D+giqlk34dLBzdVqBtk7Y3M6QnA==; Original-Received: from localhost ([127.0.0.1] helo=dancol.org) by dancol.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hCVId-0007Tt-AO; Fri, 05 Apr 2019 13:18:55 -0700 Original-Received: from 127.0.0.1 (SquirrelMail authenticated user dancol) by dancol.org with HTTP; Fri, 5 Apr 2019 13:18:55 -0700 In-Reply-To: <20190405182106.GC4208@ACM> X-Priority: 3 (Normal) Importance: Normal X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2600:3c01::f03c:91ff:fedf:adf3 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:235003 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. I'm also concerned that by overloading eq this way we'll make it easy to "lose" information about positions. In general, when (eq a b), we can substitute a for b and vice versa. The objects are equivalent in the strongest sense. Now, they're not equivalent, and choosing a instead of b can lead to subtle bugs, especially since we're talking about error-path and warning-path code that might not be frequently exercised. You mention that we'd need to change the use of EQ throughout the byte compiler in order to work with positional symbols properly. Can we just do that, in one big renaming patch? In cases where we don't want positions, we can just define a macro making the new eq-for-position function equivalent to eq. But yes, it's kind of unfortunate that we haven't been using an explicit AST representation.