From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark Oteiza Newsgroups: gmane.emacs.devel Subject: Re: if-let/if-let*/and-let/.. Date: Tue, 13 Feb 2018 14:31:26 -0500 Message-ID: <20180213193126.7ifsybvdx7cnjb4f@logos.localdomain> References: <87wozijhpk.fsf@web.de> <87mv0crbp3.fsf@web.de> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1518550207 13620 195.159.176.226 (13 Feb 2018 19:30:07 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 13 Feb 2018 19:30:07 +0000 (UTC) User-Agent: NeoMutt/20171215 Cc: emacs-devel@gnu.org, Stefan Monnier , npostavs@users.sourceforge.net To: Michael Heerdegen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 13 20:30:03 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 1elgGt-00027P-M3 for ged-emacs-devel@m.gmane.org; Tue, 13 Feb 2018 20:29:43 +0100 Original-Received: from localhost ([::1]:41805 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1elgIv-0001dL-DV for ged-emacs-devel@m.gmane.org; Tue, 13 Feb 2018 14:31:49 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40056) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1elgIj-0001Zr-T3 for emacs-devel@gnu.org; Tue, 13 Feb 2018 14:31:40 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1elgIc-0001BK-6Z for emacs-devel@gnu.org; Tue, 13 Feb 2018 14:31:37 -0500 Original-Received: from mail-qt0-x234.google.com ([2607:f8b0:400d:c0d::234]:34315) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1elgIb-0001AU-P5 for emacs-devel@gnu.org; Tue, 13 Feb 2018 14:31:30 -0500 Original-Received: by mail-qt0-x234.google.com with SMTP id d14so4932925qtg.1 for ; Tue, 13 Feb 2018 11:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=udel-edu.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=xHKbuC7qLkcvQ9HEETxKBCAjcY1aVIznZjHIgCPRQZI=; b=RCHpR55K+Y4EPVvQk9pnAnYIFHfPxwKOicdquO5F35vkUIOjYHI1N9xrnc3iVGGhhg oxBgcGNWH8XRgWPtplBKzuXF+6AxZUvuxBu52xPJlnEew3NosGa555oX9P1qab9Jx+aT 9QsTxsbam6D3xxzPyXDgcVc6JvsMvxnWN+sgGQ+wGYXROehTy0NNugR4C+gw2XGG7iHn 7ZuKw3IWU3xUOSR97TBVfgdjrQIW52NCurlhe1Fu4UnBwG30VXy1BB7+UxgYZsuUvU+I gOl3fXRsdKlzsfIs7AUfEIV4jTrRdpAH30dZFz9kpoPw0sUfBnJPvkB4IgUk7PTdn/XK UTYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=xHKbuC7qLkcvQ9HEETxKBCAjcY1aVIznZjHIgCPRQZI=; b=SyUeeLI5ertjOvJKNg8WPOjALVzq9ojnZiCHyGMM6vr6aCLI/N5/M8zmNUw+huuPTZ lamRz2oyvIyhCny3qysbEmyz82E0Znj6YViLo+rdU8J1k1GnmH8O55Nri1kNAg3Uk1S3 epSq+bF9Au4W+LkP78rrNrdCX9HYlhARCbNC7/4V9rWoNDmk3mlnaVfc6Np9eUxNnYjB xue3p50tQtbPr8g2I47/rLw9wrh5+yTI1kE8kGwZ8SFSKqaaU5pp0tI/CXk15zuCdfvF bKhzjBkp96LzzJ2DHzQprs9w3wvSA3PtkDRW7D0JATW2PJTqzU5ijge+FkKEE0Co1p+D 0Cfw== X-Gm-Message-State: APf1xPA0WZ8TREAfaGz2hHY9ExuwywtIPjh3UX6DKZhv1j+CHtMbkD7r iAzktENKNOw90wllH5bA4WJnrQ== X-Google-Smtp-Source: AH8x226p5+kE/sOIe6ctbcfuVEMA2Ur+7xQbcV03eC1p9Y3tEaQG8AT7q0ejJ+El/v/nM7qJIqMrXQ== X-Received: by 10.200.41.123 with SMTP id z56mr3521428qtz.189.1518550288500; Tue, 13 Feb 2018 11:31:28 -0800 (PST) Original-Received: from logos.localdomain (pool-173-67-36-61.bltmmd.fios.verizon.net. [173.67.36.61]) by smtp.gmail.com with ESMTPSA id u9sm8132865qtj.80.2018.02.13.11.31.27 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 13 Feb 2018 11:31:27 -0800 (PST) Content-Disposition: inline In-Reply-To: <87mv0crbp3.fsf@web.de> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:400d:c0d::234 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:222718 Archived-At: On 13/02/18 at 07:23pm, Michael Heerdegen wrote: > Stefan Monnier writes: > > > >>> - 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? > > I think it is worth it, for the same reason we keep having `when' though > we have `if' or `and': to make code better readable and its intention > better understandable. They ended up being so similar because we bestowed all the goodies from and-let* onto the other two macros. I proposed code adding and-let* so naturally I'm all about keeping it. > > >> 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) > > In my case, my brain always told me that the * name is the canonical > one, so I always got errors. I think nobody thinks through what you > said when writing code. The macros are based on let*, so why wouldn't their names reflect it? (I see the below reasoning about original vs alternate) I forget from the discussion of when these were introduced, but I think the other language's when-let from which the single binding special case was assimilated ONLY allowed a single binding, and so wouldn't have needed let* anyways. > > > 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*, ...). > > I think when using `when-let' etc. more people have the analogy to `let' > in mind than mapcar* vs. mapcar, but I see your point: the obsolescence > issue is very unpleasant. > > > > 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. > > That makes no sense, indeed. Would keeping both names as aliases be ok > to you? If we are ok with breaking code that depends on the special case (SYMBOL VALUEFORM) semantics that the original if-let and when-let had, that is: (when-let (a 1) a) then we could just make them aliases--they are separate from the {if,when}-let* simply to avoid breaking code.