From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 9dd95bf: * lisp/emacs-lisp/pcase.el (pcase--u1): Fix bignums Date: Fri, 26 Oct 2018 14:23:26 -0400 Message-ID: References: <83bm7hozav.fsf@gnu.org> <83zhv0oink.fsf@gnu.org> <83va5ooboc.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1540578106 27188 195.159.176.226 (26 Oct 2018 18:21:46 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 26 Oct 2018 18:21:46 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 26 20:21:42 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 1gG6jt-0006tI-5r for ged-emacs-devel@m.gmane.org; Fri, 26 Oct 2018 20:21:41 +0200 Original-Received: from localhost ([::1]:33707 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gG6lz-0000hG-Io for ged-emacs-devel@m.gmane.org; Fri, 26 Oct 2018 14:23:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44687) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gG6ls-0000hB-OC for emacs-devel@gnu.org; Fri, 26 Oct 2018 14:23:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gG6ln-0002I3-97 for emacs-devel@gnu.org; Fri, 26 Oct 2018 14:23:44 -0400 Original-Received: from alt22.smtp-out.videotron.ca ([70.80.0.73]:46628) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gG6lm-0002Dd-Ty for emacs-devel@gnu.org; Fri, 26 Oct 2018 14:23:39 -0400 Original-Received: from fmsmemgm.homelinux.net ([23.233.195.134]) by Videotron with SMTP id G6lagVsEpBXWOG6lbgV7jS; Fri, 26 Oct 2018 14:23:28 -0400 X-Authority-Analysis: v=2.3 cv=R4Mt5+ZX c=1 sm=1 tr=0 a=xXJ578j8WyTliCxld3/pTA==:117 a=xXJ578j8WyTliCxld3/pTA==:17 a=IkcTkHD0fZMA:10 a=smKx5t2vBNcA:10 a=GF-7kMfakOid1AksyiwA:9 a=QEXdDO2ut3YA:10 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id B3456AE31A; Fri, 26 Oct 2018 14:23:26 -0400 (EDT) In-Reply-To: <83va5ooboc.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 26 Oct 2018 20:33:23 +0300") X-CMAE-Envelope: MS4wfMiJIYEgF6f8QzJ9f2XEeqnUe65aaNPZt3+kXlQJza3hu4p3icuJFeKeSQ79Ej7BkMP2fePDFX+jEyQMS57klVEfM0bs3i7CZH2ixqewiqaMAhvjaTPE EsY1y0uabVJZX8ccSslRLrJ+ZT41jBlp33QGLpgAocPYc1nPhD+2oQ4oG/AvrMcLWJeHVAlsN+75GZOvpV9lwmHjln8cKHJoq99e4xQFEjoD09Xax3ND0I7i y8weq+UnERezCB7hyUafpQ== X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 70.80.0.73 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:230721 Archived-At: >> >> > Stefan, this change needs a suitable change in the docs (both the d= oc >> >> > string and the ELisp manual): they still claim integers are compared >> >> > using 'equal', which AFAIU is now inaccurate. >> >> AFAIK using `eql` gives the same result as comparing with `equal`: >> >> It's just an internal optimization that is transparent to the user. >> > That's so, but I find documentation that explicitly calls out 'equal' >> > misleading when the code actually invokes 'eql' instead. >> I don't understand why you feel that way. > "Feel"? The text refers to 'equal' explicitly, so it's not a feeling, > it's a fact. You say "find ... misleading", which I consider to describe a feeling of yours. Not that it matters, tho. Personally I don't find it misleading at all, as long as I can indeed rely on the fact that the code will always behave *as if* it used `equal`. >> Would you feel the same if `pcase` always used `equal` and the >> optimization to `eql` were performed in the byte-compiler instead? > I don't know, and it's not really relevant, is it? It is: the use of `eq` or `eql` here is an optimization which pcase performs only because the compiler doesn't do it. To me as a user, whether such an optimization is performed in the macro expander or in the byte-compiler is irrelevant (as long as the optimization is correct and I hence can't tell the difference). It's also relevant in the sense that all things being equal it would be better for this optimization to be performed in the byte-compiler (so that it applies not only to pcase code but to other code as well). So instead of changing the pcase doc, we could move the optimization to the byte-compiler. > How about this: > > =E2=80=98KEYWORD=E2=80=99 > =E2=80=98INTEGER=E2=80=99 > =E2=80=98STRING=E2=80=99 > Matches if EXPVAL is equal to the literal object. The equality > predicate depends on the type of the object; e.g., symbols are > compared using 'eq', and strings using 'equal'. I think we should say here that the semantics is that of `equal` and not that of `eq` (or `=3D` or whatever else). The above would allow `pcase` to use `eq` for integers. IOW if pcase uses `eq` on integers (as it did until yesterday) and some code uses pcase to match a bignum, the above would let us say that the bug is in the pcase use rather than in the pcase implementation. Compared to the current doc, it also leaves it unclear whether 1.0 would match the '1 pattern. Stefan