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: if-let/if-let*/and-let/.. Date: Mon, 12 Feb 2018 12:32:06 -0500 Message-ID: References: <87wozijhpk.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1518456870 13334 195.159.176.226 (12 Feb 2018 17:34:30 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 12 Feb 2018 17:34:30 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Mark Oteiza , npostavs@users.sourceforge.net, emacs-devel@gnu.org To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 12 18:34:26 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 1elHzJ-0001Kp-TF for ged-emacs-devel@m.gmane.org; Mon, 12 Feb 2018 18:33:58 +0100 Original-Received: from localhost ([::1]:58614 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1elI1J-00030K-QS for ged-emacs-devel@m.gmane.org; Mon, 12 Feb 2018 12:36:01 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46194) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1elHxc-0000xa-V9 for emacs-devel@gnu.org; Mon, 12 Feb 2018 12:32:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1elHxY-000464-Bu for emacs-devel@gnu.org; Mon, 12 Feb 2018 12:32:12 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:42948) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1elHxY-00044s-5O for emacs-devel@gnu.org; Mon, 12 Feb 2018 12:32:08 -0500 Original-Received: from lechazo.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id w1CHW6i0025856; Mon, 12 Feb 2018 12:32:06 -0500 Original-Received: by lechazo.home (Postfix, from userid 20848) id 5F1E460310; Mon, 12 Feb 2018 12:32:06 -0500 (EST) In-Reply-To: (Stefan Monnier's message of "Mon, 12 Feb 2018 11:58:43 -0500") X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 3 Rules triggered ATR_WMN=0.2, EDT_SA_DN_PASS=0, RV6220=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6220> : inlines <6390> : streams <1778783> : uri <2591583> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:222690 Archived-At: Resending with correct Cc. Sorry 'bout that and thanks Mark for the heads up, Stefan Stefan Monnier writes: >>> This if/when/and-let/let* business looks pretty messy to me: >>> >>> - why do we have and-let* ? According to its docstring the only case >>> when it differs from when-let* is when body is nil, but in that case >>> you're better off moving the last binding to the body (and use >>> when-let*). >> >> The discussion about this was in bug#28254. The original and-let* >> version was much more different from `when-let*', but AFAIR Noam vetoed >> against this version, so they got more similar in the end. > > Is it worth keeping this "more similar" result at all? > >> The original reason was that we decided that the names without "*" are >> quite confusing and we wanted to get rid of them in the future. > > Is the benefit of slightly reducing confusion (I really find it hard to > believe the confusion is serious, since the dependencies between the > different steps would make it rather inconvenient to provide a real > "parallel-let" semantics) worth the burden of those > compatibility/obsolescence issues (I'd also mention the confusing > aspect of having an extra * for a construct that doesn't exist without > a *, even though traditionally the * is used to mark an "alternative" > definition, as in list*, mapcar*, ...). > > Another question is why aren't when-let and when-let* aliases of > each other? Currently we have 5 variants (2 of which are deprecated) > each with very slightly different semantics. > > > Stefan > > > PS: I'm also biased against when-let* because I find this * ugly.