From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Tino Calancha Newsgroups: gmane.emacs.bugs Subject: bug#25154: 25.1; Bindings in cl-letf are in reverse order Date: Sun, 11 Dec 2016 12:11:16 +0900 Message-ID: <87zik317or.fsf@gmail.com> References: <8737hwllow.fsf@gmail.com> <83zik4fdug.fsf@gnu.org> <87bmwjy80b.fsf@gmail.com> <838trnfxlv.fsf@gnu.org> <87zik3wohp.fsf@gmail.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1481425936 7222 195.159.176.226 (11 Dec 2016 03:12:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 11 Dec 2016 03:12:16 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: npostavs@users.sourceforge.net, 25154@debbugs.gnu.org, Philipp Stephani , tino.calancha@gmail.com To: Alex Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Dec 11 04:12:12 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1cFuYd-00017b-DZ for geb-bug-gnu-emacs@m.gmane.org; Sun, 11 Dec 2016 04:12:11 +0100 Original-Received: from localhost ([::1]:53974 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFuYh-0003IO-C2 for geb-bug-gnu-emacs@m.gmane.org; Sat, 10 Dec 2016 22:12:15 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFuYX-0003Hi-SR for bug-gnu-emacs@gnu.org; Sat, 10 Dec 2016 22:12:07 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cFuYT-0002Mz-Th for bug-gnu-emacs@gnu.org; Sat, 10 Dec 2016 22:12:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50258) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cFuYT-0002Mv-Pd for bug-gnu-emacs@gnu.org; Sat, 10 Dec 2016 22:12:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cFuYT-0003wy-JN for bug-gnu-emacs@gnu.org; Sat, 10 Dec 2016 22:12:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Tino Calancha Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Dec 2016 03:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25154 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: notabug Original-Received: via spool by 25154-submit@debbugs.gnu.org id=B25154.148142588915136 (code B ref 25154); Sun, 11 Dec 2016 03:12:01 +0000 Original-Received: (at 25154) by debbugs.gnu.org; 11 Dec 2016 03:11:29 +0000 Original-Received: from localhost ([127.0.0.1]:37424 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cFuXx-0003w3-F8 for submit@debbugs.gnu.org; Sat, 10 Dec 2016 22:11:29 -0500 Original-Received: from mail-pf0-f194.google.com ([209.85.192.194]:34291) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cFuXv-0003vn-OB for 25154@debbugs.gnu.org; Sat, 10 Dec 2016 22:11:28 -0500 Original-Received: by mail-pf0-f194.google.com with SMTP id y68so2841522pfb.1 for <25154@debbugs.gnu.org>; Sat, 10 Dec 2016 19:11:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=EL3P0PCdsIyzPHHrcUC7D3OkBEUYANsQ2cJJKhWCaDE=; b=rYcTBVDwnuE8DchSE5XklXjgEByzGil3naP2mNbe0Enno7h1yBAyJiZu6bdUkkDFMt JYIEkGGU5qYXG1SszgEdn3LsgmnMgR4jTlrYlgMatyDZBcmdCzGyAq8+QNVLxkrsesYX OzvOOssahZiO2+kxYezYUilSTRdAs6067PiOrkFxiBhlVO8aMsWV+fHytw4g0h7aC2zD t/tOAOhz7w1mj9ebxsuVp34/yKjYdCX+UJqk3QN4Nr3GfCLcptoeb5/5voNFBueCY4BQ t5+nrYEqW9BRpir1Sv5R0woLWV6fAlqJWxTv83qjcPpW7z4cv389wYfJoLlL1qjIudg+ ZYEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=EL3P0PCdsIyzPHHrcUC7D3OkBEUYANsQ2cJJKhWCaDE=; b=OYONz0jkG9RRPo/PGtk8VCERKOSXSiMkK1i8J3dqXOsI/WTIyEMtSemGbzK6KIo2ap eXCgOP9IM3QBkbMuxQlm0V7+gjfLdcTXOvTSKFQcX2N24fLFqdVWFVcD/m0x16z0japf pUE//25XXjjhA1qPl1e22eDbtAbxWkyMJwAvsC24hXIl0+WGW+MFgHQ1oqVn0IssEI8L g6eWb5UP12irJcgUXWg2rAAS1oghfxas8ZfAcIF5lFH50NKjB0HFB1KF/qvD1jXktgsu UTL8gc2LvoQri2q/wfCH1r5/fYX0XX80tikBfIkvtKgF5xgh0abOkOE2Mr9NsNpaAfXz tG8Q== X-Gm-Message-State: AKaTC01O/Cai22b6x7H29XtRuPqFPqmVuhgmerwKK8w5FRJ/aicIo3d7fASnyasEeN9AZw== X-Received: by 10.99.119.71 with SMTP id s68mr157152182pgc.11.1481425881975; Sat, 10 Dec 2016 19:11:21 -0800 (PST) Original-Received: from calancha-pc (177.192.218.133.dy.bbexcite.jp. [133.218.192.177]) by smtp.gmail.com with ESMTPSA id t89sm67101381pfe.50.2016.12.10.19.11.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 10 Dec 2016 19:11:21 -0800 (PST) In-Reply-To: <87zik3wohp.fsf@gmail.com> (Alex's message of "Sat, 10 Dec 2016 13:52:34 -0600") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:126839 Archived-At: Hi Alex, thank you for your report and your time! I answer you below. >> Isn't it true that the order of evaluation in a 'let' is unspecified? >> If you want a particular order, use 'let*'. >I don't think so. See (info "(elisp) Local Variables"): > All of the VALUE-FORMs in BINDINGS are evaluated in the order they > appear Eli means here "order on the bindings assignment is unspecified in a 'let'". Programs shouldn't rely on any particular order in the assigments: it's an implementation detail. >This approximately expands to: > >(let* > ((v v) > (v w) > (old > (aref v 2)) > (old > (aref v 1))) > (unwind-protect > (progn > (aset v 2 20) > (aset v 1 10) > (aref v 1)) > (aset v 2 old) > (aset v 1 old))) > >As you can see, the arefs and asets are evaluated in reverse order. >Again, even if you argue that the order of evaluation for (PLACE VALUE) >pairs is unspecified, it's evaluating them in an unexpected way for no >good reason. There is a good reason: the result code implementing cl-letf is simpler. Your patch unnecessarily adds calls to `setq' and `nreverse'. That result in longer code and less efficient. Bear in mind that `let' and `cl-letf' are written in different languages; the former in C, the latter in elisp. As far as those implementations satisfy their specification, the simpler and more efficient that they can be the better. >> The value forms are evaluated in order, the bindings are not necessarily >> in order. >> >> (let ((x 0)) >> (cl-letf ((a (setq x 1)) >> (a (setq x 2))) >> (list x a))) ;=> (2 1) > >Right, this expands to: > >(let ((x 0)) > (let* > ((vnew > (setq x 1)) > (vnew > (setq x 2)) > (a vnew) > (a vnew)) > (unwind-protect > (list x a)))) > >Which, outside of the case of repeating the variable name (which >arguably shouldn't be allowed like in some other Lisps), doesn't matter. > >It only matters when using more complex places like > >(cl-letf (((aref v 1) 10) > ((aref w 2) 20)) > (aref v 1)) No it doesn't matter, because as pointed out above the order to perform the parallel bindings is unspecified. It might start binding from left to right, or right to left, or even random order using the current time as a seed. Code relying in a particular order for those bindings is not portable, even more, it has a bug; we might change the implemention in the future for whatever reason producing a different order: then such code will break. If you want the bindings being perform from left to right, then you just need to use sequential `letf*'/`cl-letf*' instead of the parallel `let'/`cl-letf'. >Just the (nreverse simplebinds) line, which I added just to make cl-letf >a little bit saner (i.e. more like let). This part does seem to be >unspecified, but I don't see why it should unnecessarily diverge from >let. In addition to result in a simpler implementation, it's useful as a reminder that code shouldn't assume a particular order. Even if i don't see any problem with `cl-letf' implementation, i agree with Philipp and Eli that it would be worth if the outcome of this report is an improvement in the documentation. We might update the manual adding a more precise statement to clarify that the order to perform the parallel bindings is unspecified, i.e., code should not assume a particular order. As Eli said patches are welcome. Alex, are you willing to prepare those doc patches? Thank you very much, Tino