From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.help Subject: RE: Always using let* Date: Mon, 15 Sep 2014 09:15:09 -0700 (PDT) Message-ID: <022a6bc4-ba00-4f09-aa04-73186faa911a@default> References: <87fvfukmso.fsf@Equus.decebal.nl> <87mwa1lhb1.fsf@kuiper.lan.informatimago.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1410797768 2858 80.91.229.3 (15 Sep 2014 16:16:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Sep 2014 16:16:08 +0000 (UTC) To: Stefan Monnier , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Sep 15 18:16:01 2014 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XTYwY-0004Tk-Ei for geh-help-gnu-emacs@m.gmane.org; Mon, 15 Sep 2014 18:15:58 +0200 Original-Received: from localhost ([::1]:32826 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTYwY-0001HX-0G for geh-help-gnu-emacs@m.gmane.org; Mon, 15 Sep 2014 12:15:58 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42690) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTYw3-0001Ba-Aa for help-gnu-emacs@gnu.org; Mon, 15 Sep 2014 12:15:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XTYvq-0006Xc-QW for help-gnu-emacs@gnu.org; Mon, 15 Sep 2014 12:15:27 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:48553) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTYvq-0006XV-Kb for help-gnu-emacs@gnu.org; Mon, 15 Sep 2014 12:15:14 -0400 Original-Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s8FGFD0V007672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 15 Sep 2014 16:15:13 GMT Original-Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8FGFB0b009656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 15 Sep 2014 16:15:12 GMT Original-Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s8FGFBFg017978; Mon, 15 Sep 2014 16:15:11 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.8.2 (807160) [OL 12.0.6691.5000 (x86)] X-Source-IP: acsinet22.oracle.com [141.146.126.238] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:99931 Archived-At: sm> So, I stand by my claim: it's an Urban Legend. But your claim changes with each post. What you first claimed was an urban legend was my statement that: "for some Lisps the bindings of `let' can be done in parallel" ^^^^^^^^^^^^ Your next message confirmed that that statement is true (though for some reason you put "parallel" in quotes and strengthened the assertion to "is" from "can be done"): sm> Only the var-binding is "parallel", not the computation sm> of each value. The bindings are exactly what my statement claimed, and what your first "Urban legend!" cry denounced. And what your latest message confirms. The myth ("legend") is a myth. `let' (vs `let*') is indeed about the _bindings_ being independent, so making it _possible_ to carry them out in parallel. That is the only thing specified for Common Lisp. And that is the only thing that makes sense for a language such as Lisp that allows side effects during evaluation. That is, it is not possible to arbitrarily parallelize evaluation of the sexps whose values are bound. (And yes, my followup message spoke of "parallel evaluation", but I again meant creation of the bindings. Admittedly, I was not as clear as I should have been there.) As Pascal pointed out, in some concrete cases analysis can reveal independency, which could be exploited for parallel execution. But as others then pointed out, this is also true generally, including for `let*'. The question of possibly parallelizing evaluation of the sexps whose values are to be bound is a side point (red herring). The point of what CLTL(2) has to say about `let', which was my point, is that `let' allows for parallelizing the _bindings_. And on that, you apparently agree now, in spite of the alarmist messages. --- Note: When I mentioned this binding independence/parallelism point in passing, I put it in _parentheses_, pretty much as an afterthought to the main reason I gave for the existence of `let' in addition to `let*' and why/when one might want to use the former. I mentioned it only because it is explicitly part of the design rationale for `let' vs `let*' in Common Lisp. Putting that in parens did not stop people from getting all excited about it, unfortunately, starting with your "Urban legend!" alarm.