From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Pascal J. Bourguignon" Newsgroups: gmane.emacs.help Subject: Re: Always using let* Date: Mon, 15 Sep 2014 04:59:46 +0200 Organization: Informatimago Message-ID: <87mwa1lhb1.fsf@kuiper.lan.informatimago.com> References: <87fvfukmso.fsf@Equus.decebal.nl> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1410750327 599 80.91.229.3 (15 Sep 2014 03:05:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Sep 2014 03:05:27 +0000 (UTC) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Mon Sep 15 05:05:22 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 1XTMbP-0000mm-Hw for geh-help-gnu-emacs@m.gmane.org; Mon, 15 Sep 2014 05:05:19 +0200 Original-Received: from localhost ([::1]:56953 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XTMbO-0003zg-R4 for geh-help-gnu-emacs@m.gmane.org; Sun, 14 Sep 2014 23:05:18 -0400 Original-Path: usenet.stanford.edu!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail Original-Newsgroups: gnu.emacs.help Original-Lines: 43 Original-X-Trace: individual.net OZDirqUsEfmlRq06LRGeyA767aqcoLX7u2KOKepOX4g8MY2EiD Cancel-Lock: sha1:NzM5NjA5YWM0YzZjNGZlZWEzZGNjYTQxOTdlYjZlMzMxMDNjZTFiYg== sha1:rXvCvRQmequC+GYuBe21VoYQSNw= Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwAQMAAABtzGvEAAAABlBMVEUAAAD///+l2Z/dAAAA oElEQVR4nK3OsRHCMAwF0O8YQufUNIQRGIAja9CxSA55AxZgFO4coMgYrEDDQZWPIlNAjwq9 033pbOBPtbXuB6PKNBn5gZkhGa86Z4x2wE67O+06WxGD/HCOGR0deY3f9Ijwwt7rNGNf6Oac l/GuZTF1wFGKiYYHKSFAkjIo1b6sCYS1sVmFhhhahKQssRjRT90ITWUk6vvK3RsPGs+M1RuR mV+hO/VvFAAAAABJRU5ErkJggg== X-Accept-Language: fr, es, en User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) Original-Xref: usenet.stanford.edu gnu.emacs.help:207622 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:99896 Archived-At: Stefan Monnier writes: >> Lisps such as Common Lisp were specifically designed with this >> parallel evaluation in mind. The spec (and CLTL(2)) specifically >> emphasizes the inherent parallelism (independence) here that >> implies the *possibility* of parallel evaluation. > > I simply claim that this is bogus. Only the var-binding is "parallel", not > the computation of each value. So it's a "parallel binding" semantics, > but it has nothing to do with efficient execution on multiple > execution units. The claim is not bogus. It's just that in general, in presence of side effects, since the expressions must be evaluated from left to right, indeed, only the assignments can be performed in parallel. But if you have side-effect free expressions, (or at least, provably independent ones), then they could be evaluated in parallel despite the left-to-right rule. On the other hand, with setf, this could not be the case. (let ((a 100) (b 200)) (psetf a (loop repeat b finally (return 1)) b (loop repeat a finally (return 2)))) could evaluate both loops in parallel, and therefore finishing by assinging 1 to a and 2 to be after only 200 iterations instead of 300. On the other hand: (let ((a 100) (b 200)) (setf a (loop repeat b finally (return 1)) b (loop repeat a finally (return 2)))) must perform 101 iterations, sequentially 100 followed by 1. -- __Pascal Bourguignon__ http://www.informatimago.com/ “The factory of the future will have only two employees, a man and a dog. The man will be there to feed the dog. The dog will be there to keep the man from touching the equipment.” -- Carl Bass CEO Autodesk