all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Emanuel Berg <embe8573@student.uu.se>
To: help-gnu-emacs@gnu.org
Subject: Re: What does "lacks a prefix" mean?
Date: Sun, 12 Jul 2015 00:42:54 +0200	[thread overview]
Message-ID: <87zj32pb81.fsf@nl106-137-147.student.uu.se> (raw)
In-Reply-To: jwvd200q794.fsf-monnier+gmane.emacs.help@gnu.org

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> let* says "I need variables which depend on each
>> other" and if they're really not, that
>> look strange.
>
> If let behaved like let* it wouldn't look strange to
> you. Many other functional languages dropped the
> "simultaneous let" and only kept the equivalent of
> let* (or even letrec).
>
>> And probably it's a bit slower.
>
> Regarding efficiency, there's no clear winner
> between the two. It's basically irrelevant.
>
>> And non-parallelizable theoretically :)
>
> In practice neither is easily parallelizable anyway.
> And the work needed to auto-convert a "let*" to
> a "let" when possible is trivial in comparison to
> what's needed to parallelize the code. So again,
> it's really irrelevant.

Hear? I couldn't have said it better myself. Wait...
I couldn't! But let me say a couple of other things:

1) "let" looks better and is faster to type, both in
   terms of the number of chars used and what those
   chars are (i.e., no "*" in "let" which is only
   normal letters).

2) With the let/let* distinction, while let* being the
   oddball, it sends the signal that the "let" style,
   and not the one of "let*", is the one preferred.
   But it is actually the "let*" style that should be
   favored! It is much more clear and
   easily navigated. Compare:

        (setq side 3.0)

        (let ((cube-volume (* side side side)))
          cube-volume)

   vs.

        (let* ((side 3.0)
               (side-area   (* side side))
               (cube-volume (* side-area side)) )
          cube-volume)

    "Dependencies" are the most natural things and
    aren't anything to be afraid of! Only if you are
    the manager of a Linux distro they can get out of
    hands sometimes...

3) "let", if let was let*, would be less thinking in
   advance since then you wouldn't have to think "so,
   will I have variables now which will depend on
   each other?" You'd just type "let" in either case!
   Likewise, when you modify code long after you
   first wrote it, you often insert a new variable
   that is "dependent" on another, and then you have
   to change the `let' to `let*'. But this is very
   easy to forget and it is always a silly mistake
   when it happens.

-- 
underground experts united
http://user.it.uu.se/~embe8573




  reply	other threads:[~2015-07-11 22:42 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-08 16:32 What does "lacks a prefix" mean? BobD
2015-07-08 16:45 ` Barry Margolin
2015-07-08 16:59 ` Vaidheeswaran C
2015-07-08 17:10 ` Vaidheeswaran C
2015-07-08 18:17 ` BobD
2015-07-08 18:21   ` Pascal J. Bourguignon
2015-07-08 18:45     ` BobD
2015-07-08 23:24       ` Emanuel Berg
2015-07-09 15:23         ` Filipp Gunbin
2015-07-09 22:32           ` Emanuel Berg
2015-07-10 17:04             ` Stefan Monnier
2015-07-11 22:42               ` Emanuel Berg [this message]
     [not found]               ` <mailman.6748.1436654668.904.help-gnu-emacs@gnu.org>
2015-07-11 23:58                 ` Barry Margolin
2015-07-13 12:26               ` Filipp Gunbin
     [not found]             ` <mailman.6685.1436547891.904.help-gnu-emacs@gnu.org>
2015-07-10 18:27               ` Barry Margolin
     [not found]         ` <mailman.6612.1436455429.904.help-gnu-emacs@gnu.org>
2015-07-09 23:27           ` Barry Margolin
     [not found]             ` <mailman.6643.1436488423.904.help-gnu-emacs@gnu.org>
2015-07-10  0:49               ` Pascal J. Bourguignon
2015-07-10  5:04                 ` Drew Adams
2015-07-10 14:42               ` Barry Margolin
     [not found]               ` <<barmar-2BC802.10421910072015@88-209-239-213.giganet.hu>
2015-07-10 14:53                 ` Drew Adams
     [not found]           ` <<barmar-500871.19271109072015@88-209-239-213.giganet.hu>
2015-07-10  0:33             ` Drew Adams
     [not found]       ` <mailman.6590.1436397914.904.help-gnu-emacs@gnu.org>
2015-07-09 14:01         ` Barry Margolin
2015-07-09 14:10           ` Rusi
2015-07-09 22:27             ` Emanuel Berg
     [not found]             ` <mailman.6639.1436481016.904.help-gnu-emacs@gnu.org>
2015-07-10  3:10               ` Rusi
2015-07-10 16:00                 ` Emanuel Berg
2015-07-09 22:19           ` Emanuel Berg
     [not found]         ` <<barmar-F23189.10014209072015@88-209-239-213.giganet.hu>
2015-07-09 15:33           ` Drew Adams
2015-07-12  1:47             ` Emanuel Berg
2015-07-12 16:59               ` Drew Adams
2015-07-13  0:46                 ` Emanuel Berg
2015-07-13  7:26                   ` Yuri Khan
2015-07-13 23:47                     ` Emanuel Berg
2015-07-14  6:23                       ` Yuri Khan
2015-07-14 21:58                         ` Emanuel Berg
2015-07-19  0:59                         ` Robert Thorpe
2015-07-28  0:24                           ` Emanuel Berg
2015-07-30  1:40                             ` Robert Thorpe
     [not found]                             ` <mailman.7638.1438220428.904.help-gnu-emacs@gnu.org>
2015-07-30  2:49                               ` Rusi
2015-07-30  2:53                                 ` Rusi

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

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

  git send-email \
    --in-reply-to=87zj32pb81.fsf@nl106-137-147.student.uu.se \
    --to=embe8573@student.uu.se \
    --cc=help-gnu-emacs@gnu.org \
    /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.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.