From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Michael Heerdegen Newsgroups: gmane.emacs.bugs Subject: bug#28254: 26.0.50; SRFI-2 and-let* Date: Tue, 12 Sep 2017 20:44:11 +0200 Message-ID: <87k213oiys.fsf@drachen> References: <20170902021043.GA7509@holos.localdomain> <878thx7qcc.fsf@users.sourceforge.net> <20170902041424.GA21189@holos.localdomain> <87tw0lzn7w.fsf@drachen> <20170902133604.GA27251@holos.localdomain> <20170904011356.GA21128@holos.localdomain> <20170905035548.GB11331@holos.localdomain> <20170909003355.GA3363@holos.localdomain> <87efrcccps.fsf@drachen> <20170912130947.GA23119@holos.localdomain> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1505338235 14137 195.159.176.226 (13 Sep 2017 21:30:35 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 13 Sep 2017 21:30:35 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: 28254@debbugs.gnu.org, Noam Postavsky To: Mark Oteiza Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Sep 12 20:45:12 2017 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 1drqBH-00050h-9s for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Sep 2017 20:45:07 +0200 Original-Received: from localhost ([::1]:38113 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drqBO-0003di-Ep for geb-bug-gnu-emacs@m.gmane.org; Tue, 12 Sep 2017 14:45:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57764) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1drqBG-0003bK-GQ for bug-gnu-emacs@gnu.org; Tue, 12 Sep 2017 14:45:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1drqBD-00040u-BR for bug-gnu-emacs@gnu.org; Tue, 12 Sep 2017 14:45:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55862) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1drqBD-00040p-7S for bug-gnu-emacs@gnu.org; Tue, 12 Sep 2017 14:45:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1drqBD-0008Dr-16 for bug-gnu-emacs@gnu.org; Tue, 12 Sep 2017 14:45:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Michael Heerdegen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 12 Sep 2017 18:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28254 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 28254-submit@debbugs.gnu.org id=B28254.150524187031529 (code B ref 28254); Tue, 12 Sep 2017 18:45:02 +0000 Original-Received: (at 28254) by debbugs.gnu.org; 12 Sep 2017 18:44:30 +0000 Original-Received: from localhost ([127.0.0.1]:36308 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drqAg-0008CT-E6 for submit@debbugs.gnu.org; Tue, 12 Sep 2017 14:44:30 -0400 Original-Received: from mout.web.de ([212.227.17.11]:59417) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1drqAf-0008CD-6B for 28254@debbugs.gnu.org; Tue, 12 Sep 2017 14:44:29 -0400 Original-Received: from drachen.dragon ([194.166.167.125]) by smtp.web.de (mrweb102 [213.165.67.124]) with ESMTPSA (Nemesis) id 0MgO8g-1e6mFO40pS-00Nkwu; Tue, 12 Sep 2017 20:44:13 +0200 In-Reply-To: <20170912130947.GA23119@holos.localdomain> (Mark Oteiza's message of "Tue, 12 Sep 2017 09:09:47 -0400") X-Provags-ID: V03:K0:5EOQFgQX4RgmHDgO96euozaAVBOO7UDCi7GSNqyguuNRcuXyZW7 PtA0r+B6oivqq/IZ2vA3UdbBxI+jxxiT0PcB3g7VJk1SGHE45/Llw8bWlbN7f8CUnQLRvU1 1jKJU5u8JcJxLvjNP7P8IEeexRhmzQHO3bochMQJ6nUoDS2r5eu6pXkO0sIYkXYs9D/bRGJ qXmHIiv46unOvsVQq79qA== X-UI-Out-Filterresults: notjunk:1;V01:K0:v6c2mnXij2s=:VD90ynlZWimLewYAFRjaHV bL8ov2CC/wLo0Vz43f/mm8veW4iNLiQmg/3hzurTpofoiPl/q4oR4cwlZ8My3TNTElitSeeo7 zxuvRRcBUzlQ9GBYY29b1qyDtd4+kmOtzelTH0HjAtA0kcRuBIlxLIxOBRKwTe2ulDrwY9l5U l3DUUuHoZ64JsEXIdYlnQSqlslGw5V2lYnx5xm/Yi2EylkkdOxZM2L4Kvhpdin1LIZ/r1IHTV qqlU8qMYsxp74ry/DYu8CLrdDie3p4GYgWGMDdJXiF8VQ1Rh5Z+04XrYFdnytlH5USoQ18PbS CH3i5siWb1kDI/nxWQ+bZkkIxN5IB76B9AcjG3R14VsdChJ2wn+pwbfGeORXRo3IL7qIeDS9G jZqqzQcqzYfqIaFL1iIUboPqyIjwdGXjE9vmTIL3nM+XgBLnJbRa8WnE+004i2fZpx8Ak5IPm KZz0xh8FZ3Ib3+nU93zX96nZq9z285z9q7VTr6nR+BiOPlOwhdUYcPjh1OlsatXFD8kRaUeOv 4InGvcJzRqHoRB9CObUc3JYnZUE9Rel/ZGpSwFz/XqRMtMFgDFdrYETXHLfNqzcJoVEtb7E6C iGw+uz7S7Onk/NQvPa32KAlLznIcQ6UYfH+LBnB92cEtYsIus4kcYnblymsFt7jyLHO6kxBox 1tPBQ8wgFnJgAavmM/ZTU07cSbeIvIvZcTFGP3lxSDJ18OBGSsz7C3W8nxaupBhtxNSv7aTPr BHwl1lGHdYYxQFM1pW+326nZepkd2ljUmN+4a+19YM1STfMUVCTtNLg4HKARPiSx+5WaXM+y 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:136939 Mark Oteiza writes: > > Not really related to your change, but: Maybe we should additionally > > say that THEN can refer to the bindings made in the VARLIST, but > > ELSE to none, not even to those that resulted in non-nil values > > before "failing". > > That's not true though--you can refer to the bindings in either branch: Hmm, that feels strange. FWIW, all the scheme implementations I looked at implemented it in a way that binding variables stops after the first nil. OTOH I would expect that all bindings are only available from the THIS branch (this is my personal opinion). In our case, we have something third: always all bindings are visible in the ELSEs, e.g. (let ((z 1)) (if-let* ((nil) (z 100)) (doesnt-matter) z)) ==> nil That doesn't feel right. I have two more questions: In `internal--listify': (defsubst internal--listify (elt) "Wrap ELT in a list if it is not one. If ELT is of the form ((EXPR)), listify (EXPR) with a dummy symbol." (cond ((symbolp elt) (list elt elt)) ((and (null (cdr elt)) (let ((form (car elt))) (or (listp form) (atom form)))) (list (make-symbol "s") (car elt))) (t elt))) isn't (or (listp form) (atom form)) always true? Secondly, in `internal--build-binding-value-form': (defsubst internal--build-binding-value-form (binding prev-var) "Build the conditional value form for BINDING using PREV-VAR." (let ((var (car binding))) (if (and (null (cdr binding)) (atom (car binding)) (not (symbolp (car binding)))) `(,var (and ,prev-var ,var)) `(,var (and ,prev-var ,(cadr binding)))))) how can it happen that (car binding) is an atom but not symbolp? And if (car binding) == var is not a symbol, how does the returned binding make sense? Thanks, Michael.