all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: arthur miller <arthur.miller@live.com>
To: Drew Adams <drew.adams@oracle.com>, Eli Zaretskii <eliz@gnu.org>,
	"Alfred M. Szmidt" <ams@gnu.org>
Cc: "yuri.v.khan@gmail.com" <yuri.v.khan@gmail.com>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Sv: [External] : Re: Is this a bug in while-let or do I missunderstand it?
Date: Sat, 9 Nov 2024 19:32:57 +0000	[thread overview]
Message-ID: <DU2PR02MB1010973AF0F33B33BB48C6F36965E2@DU2PR02MB10109.eurprd02.prod.outlook.com> (raw)
In-Reply-To: <DS7PR10MB5232C33CCF081931A5C83DBEF35E2@DS7PR10MB5232.namprd10.prod.outlook.com>

[-- Attachment #1: Type: text/plain, Size: 3125 bytes --]

>IMHO, this is a problem with all of the
>if/and/when/while-let[*] thingies.

Only while-let.

>uses them a lot then she probably knows what
>goes on, in what sequence.  But a priori it's
>not so clear.
>
>This may just mean that the doc needs to take
>pains to be very clear, maybe even with examples
>or by showing a macro expansion explicitly.
>
>Using catch/throw, let[*], and/if/when/while
>together is always _clearer_, IMO.  And it's
>often no more verbose.  Witness all of the

I don't think so. As much as I have understood
if-let, when-let and unique for elisp while-let,
are an "informal formalization", or just a shorthand
for following idiom:

(let ((some-var init-form))
  (if some-var than-form else-form))

Similar for when-let. Consider also a bigger piece
of code, where you have longer let-form, and want
to do some loop:

(let ((var1 init1)
      ...
      (varN initN)
      (loop-invarant init-loop-invariang))

  ....
  (while loop-invariant
    ...)

 ...)

In this context you are leaking loop-invariant in the
entire scope of enclosing let-form, whereas

(let ((var1 init1)
      ...
      (varN initN))

  ....
  (while ((loop-invariant init-loop-invariant))
    ...)

 ...)

limits 'loop-invariant' to the lexical environment
of while loop. You can compare this to pre- C++11
standards where compilers would leak loop invariants
after the scope of the loop:

   for (int i=0; i<10; i++) {
      ...
   }

   i = 2; <-- i visible outside of the for-loop scope

Limiting scope of variables to the lexical scope
where they matter helps to minimize accidental
usages, and also make code easier to read and understand.
________________________________
Från: Drew Adams <drew.adams@oracle.com>
Skickat: den 9 november 2024 19:07
Till: Eli Zaretskii <eliz@gnu.org>; Alfred M. Szmidt <ams@gnu.org>
Kopia: yuri.v.khan@gmail.com <yuri.v.khan@gmail.com>; arthur.miller@live.com <arthur.miller@live.com>; emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: RE: [External] : Re: Is this a bug in while-let or do I missunderstand it?

IMHO, this is a problem with all of the
if/and/when/while-let[*] thingies.  If someone
uses them a lot then she probably knows what
goes on, in what sequence.  But a priori it's
not so clear.

This may just mean that the doc needs to take
pains to be very clear, maybe even with examples
or by showing a macro expansion explicitly.

Using catch/throw, let[*], and/if/when/while
together is always _clearer_, IMO.  And it's
often no more verbose.  Witness all of the
discussion about <X>-let* versus <X>-let names
and this current discussion.  The name itself
doesn't clearly tell you what it does... which
is OK, but only if the doc tells you that
clearly.

I'm not saying no one should use, or Elisp
shouldn't provide, if/and/when/while-let[*]
thingies.  I'm just saying (1) I don't find
them helpful, personally (I don't use them),
and (more importantly) (2) if we provide them
then their doc needs to be very specific about
what _exactly_ they do, and when (if not also
how).

[-- Attachment #2: Type: text/html, Size: 11262 bytes --]

  parent reply	other threads:[~2024-11-09 19:32 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-08 16:25 Is this a bug in while-let or do I missunderstand it? arthur miller
2024-11-08 19:23 ` Philip Kaludercic
2024-11-09  3:30   ` Sv: " arthur miller
2024-11-09  9:29 ` Yuri Khan
2024-11-09 13:03   ` Sv: " arthur miller
2024-11-09 13:15     ` Yuri Khan
2024-11-09 13:38       ` Sv: " arthur miller
2024-11-09 13:41         ` Yuri Khan
2024-11-09 13:47           ` Sv: " arthur miller
2024-11-09 14:04             ` Yuri Khan
2024-11-09 14:44               ` Sv: " arthur miller
2024-11-09 16:33               ` Alfred M. Szmidt
2024-11-09 16:44                 ` Eli Zaretskii
2024-11-09 16:53                   ` Eli Zaretskii
2024-11-09 17:33                   ` Andreas Schwab
2024-11-09 18:07                   ` [External] : " Drew Adams
2024-11-09 18:18                     ` Alfred M. Szmidt
2024-11-09 20:02                       ` Jens Schmidt
2024-11-09 20:38                         ` Alfred M. Szmidt
2024-11-09 21:18                           ` Joost Kremers
2024-11-10 11:44                         ` Alfred M. Szmidt
2024-11-10 12:24                           ` Better documentation for non-binding clauses of if-let and friends Jens Schmidt
2024-11-10 14:51                             ` Sean Whitton
2024-11-10 16:58                               ` Jens Schmidt
2024-11-11 10:03                               ` Alfred M. Szmidt
2024-11-11  8:20                             ` Alfred M. Szmidt
2024-11-09 19:32                     ` arthur miller [this message]
2024-11-09 22:36                       ` [External] : Re: Is this a bug in while-let or do I missunderstand it? Drew Adams
2024-11-09 22:53                         ` Drew Adams
2024-11-14 21:50                   ` John ff
2024-11-09 20:29                 ` Sv: " arthur miller
2024-11-10  6:22                   ` Eli Zaretskii
2024-11-10 10:40                     ` Joost Kremers
2024-11-10 12:10                       ` Alfred M. Szmidt
2024-11-10 19:49                         ` Sv: " arthur miller
2024-11-10 18:18                     ` arthur miller
2024-11-11  5:13                       ` Yuri Khan
2024-11-11  8:49                         ` Sv: " arthur miller
2024-11-11 12:23                           ` tomas
2024-11-11 22:41                     ` Joost Kremers
2024-11-12 12:19                       ` Eli Zaretskii
2024-11-12 12:45                         ` Joost Kremers
2024-11-12 14:34                           ` Eli Zaretskii
2024-11-12 15:32                             ` Joost Kremers
2024-11-12 23:45                         ` Joost Kremers
2024-11-13  9:45                           ` Sean Whitton
2024-11-13  9:56                             ` Sean Whitton
2024-11-13 11:00                               ` Joost Kremers
2024-11-13 12:17                                 ` Sean Whitton
2024-11-14  7:55                                 ` Eli Zaretskii
2024-11-14  8:21                                   ` Joost Kremers
2024-11-14 21:51                               ` John ff
2024-11-14 21:52                                 ` John ff
2024-11-09 21:47             ` Sv: " Joost Kremers
2024-11-09 22:07               ` Sv: " arthur miller
2024-11-10  6:07               ` Andreas Schwab

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=DU2PR02MB1010973AF0F33B33BB48C6F36965E2@DU2PR02MB10109.eurprd02.prod.outlook.com \
    --to=arthur.miller@live.com \
    --cc=ams@gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=yuri.v.khan@gmail.com \
    /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.