From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alex Newsgroups: gmane.emacs.bugs Subject: bug#25154: 25.1; Bindings in cl-letf are in reverse order Date: Sat, 10 Dec 2016 13:41:04 -0600 Message-ID: <874m2by3lb.fsf@gmail.com> References: <8737hwllow.fsf@gmail.com> <83zik4fdug.fsf@gnu.org> <87bmwjy80b.fsf@gmail.com> <87bmwjejmp.fsf@users.sourceforge.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1481398933 14527 195.159.176.226 (10 Dec 2016 19:42:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 10 Dec 2016 19:42:13 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: 25154@debbugs.gnu.org To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Dec 10 20:42:09 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 1cFnX5-0002f0-5l for geb-bug-gnu-emacs@m.gmane.org; Sat, 10 Dec 2016 20:42:07 +0100 Original-Received: from localhost ([::1]:52888 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFnX9-00026Y-86 for geb-bug-gnu-emacs@m.gmane.org; Sat, 10 Dec 2016 14:42:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40587) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cFnX3-00026R-KM for bug-gnu-emacs@gnu.org; Sat, 10 Dec 2016 14:42:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cFnX0-0006Il-I5 for bug-gnu-emacs@gnu.org; Sat, 10 Dec 2016 14:42:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:50099) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cFnX0-0006If-DH for bug-gnu-emacs@gnu.org; Sat, 10 Dec 2016 14:42:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cFnX0-0007eu-2k for bug-gnu-emacs@gnu.org; Sat, 10 Dec 2016 14:42:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Alex Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Dec 2016 19:42:02 +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.148139887429379 (code B ref 25154); Sat, 10 Dec 2016 19:42:02 +0000 Original-Received: (at 25154) by debbugs.gnu.org; 10 Dec 2016 19:41:14 +0000 Original-Received: from localhost ([127.0.0.1]:37265 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cFnWD-0007dm-PM for submit@debbugs.gnu.org; Sat, 10 Dec 2016 14:41:13 -0500 Original-Received: from mail-io0-f176.google.com ([209.85.223.176]:32899) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cFnWC-0007dZ-IN for 25154@debbugs.gnu.org; Sat, 10 Dec 2016 14:41:12 -0500 Original-Received: by mail-io0-f176.google.com with SMTP id d9so110626481ioe.0 for <25154@debbugs.gnu.org>; Sat, 10 Dec 2016 11:41:12 -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=N9IVPrvh0tDl6nSqnL9Pgq8Sdb4yC1N5FS31C7WGCuM=; b=ydU3ReRgmzncDjwemNpE8H6j6rAeSqovEcCih1TbRYMFfLLHwINWjRmLVXJdn2j2MQ 6/mmW8vcSbHiW6ACb26SRPcfhG1E1mTZ6wiOqfnM6Eu/0CuAhwzOMhK4wCoSSCYGcWwO TCtGn42lmsLmMFOf/VovDlaDS5x3T3M9gb0fgfGffavKCSdZAnxS/r/Bso+fimn6VJb3 7mDObaOangBc+Sv8I0yu05D9E6RaGk1Da1nIVnFDPE5zrXQPYfMWr+loxvVXBKcoIMTh RTI/jeITcWNI1mgfPmkVwVNNt+egt4rKMEPTMz7dONeqMe9Zaf+26pC6Vi2YxdG5466c FY/A== 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=N9IVPrvh0tDl6nSqnL9Pgq8Sdb4yC1N5FS31C7WGCuM=; b=MiAoE/9/I9Mv+3cg08LrWYndHICxD5AM/cbKE944DQ54UlDCOjYskYgmqOkm5wxqHn JyMuGFEehp1c5eTmEpjw4lT3W5vBrCxnuVga8ki59Dx8zCjhAvGZ0MpLlR3uAtdK65ZN BXtdFB0pw5RMMAkBLHNmefsPIylHS7BM6ud9AuYjLKt0ooiIMfVklg0bdgyw2jKIZcKo hA9T+bFHS67yq34CrJCRVOZt3ir75VFlV/oiQlk+vJ07Lkfwtoe5PGLV+YxhS/NrWjxi mELZHBl1HsPdRvKSCvdyX3EAR8UGwaaWHY//AjJxt+hR21asZSdeVcgruPLMYif3mASW dTtg== X-Gm-Message-State: AKaTC005DO0p3UL4+eIjyJClA7Dq616cxGEs9oRreTfqhcPLKvlmWwQwmnGxddrYjTWMrg== X-Received: by 10.36.83.15 with SMTP id n15mr3885901itb.79.1481398866744; Sat, 10 Dec 2016 11:41:06 -0800 (PST) Original-Received: from lylat (S01061859339e9903.ss.shawcable.net. [174.2.107.88]) by smtp.gmail.com with ESMTPSA id j201sm9204196ita.2.2016.12.10.11.41.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sat, 10 Dec 2016 11:41:06 -0800 (PST) In-Reply-To: <87bmwjejmp.fsf@users.sourceforge.net> (npostavs@users.sourceforge.net's message of "Sat, 10 Dec 2016 13:14:54 -0500") 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:126826 Archived-At: npostavs@users.sourceforge.net writes: > Alex writes: > >>> >>> 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 >> >> I believe it should follow for cl-letf. Besides, even if it was >> unspecified, evaluating in the order they appear would be adhering to >> the principle of least astonishment. > > 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))