unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>, help-gnu-emacs@gnu.org
Subject: RE: Always using let*
Date: Mon, 15 Sep 2014 09:15:09 -0700 (PDT)	[thread overview]
Message-ID: <022a6bc4-ba00-4f09-aa04-73186faa911a@default> (raw)
In-Reply-To: <jwvegvdgje8.fsf-monnier+gmane.emacs.help@gnu.org>

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.



  reply	other threads:[~2014-09-15 16:15 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-14 19:46 Always using let* Cecil Westerhof
2014-09-14 21:25 ` Drew Adams
2014-09-15 16:15   ` Drew Adams
     [not found]   ` <mailman.8924.1410797740.1147.help-gnu-emacs@gnu.org>
2014-09-15 18:01     ` Cecil Westerhof
2014-09-15 22:20       ` Emanuel Berg
2014-09-16 12:05         ` Cecil Westerhof
2014-09-16 22:40           ` Emanuel Berg
2014-09-18 17:02             ` Cecil Westerhof
2014-09-18 21:05               ` Emanuel Berg
2014-09-16 14:23     ` sokobania.01
2014-09-16 16:41       ` Drew Adams
2014-09-16 20:49       ` Stefan Monnier
2014-09-16 22:45       ` Emanuel Berg
     [not found]       ` <mailman.8998.1410901776.1147.help-gnu-emacs@gnu.org>
2014-09-16 22:48         ` Emanuel Berg
2014-09-17  1:09           ` Stefan Monnier
2014-09-17  1:18             ` Emanuel Berg
2014-09-14 21:40 ` Joe Fineman
     [not found] ` <mailman.8868.1410729956.1147.help-gnu-emacs@gnu.org>
2014-09-14 21:41   ` Emanuel Berg
2014-09-14 22:11   ` Cecil Westerhof
2014-09-14 22:56     ` Drew Adams
2014-09-14 22:41   ` Stefan Monnier
2014-09-14 23:06     ` Drew Adams
     [not found]     ` <mailman.8871.1410736002.1147.help-gnu-emacs@gnu.org>
2014-09-15  0:47       ` Emanuel Berg
2014-09-15  2:12         ` Pascal J. Bourguignon
2014-09-15  2:22       ` Stefan Monnier
2014-09-15  2:59         ` Pascal J. Bourguignon
2014-09-15 12:31           ` Stefan Monnier
2014-09-15 16:15             ` Drew Adams [this message]
2014-09-15 19:05               ` Stefan Monnier
     [not found]               ` <mailman.8930.1410808006.1147.help-gnu-emacs@gnu.org>
2014-09-15 22:28                 ` Emanuel Berg
2014-09-16  0:38                   ` Pascal J. Bourguignon
2014-09-15 13:14           ` Barry Margolin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=022a6bc4-ba00-4f09-aa04-73186faa911a@default \
    --to=drew.adams@oracle.com \
    --cc=help-gnu-emacs@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).