all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Joost Kremers <joostkremers@fastmail.fm>
To: Eli Zaretskii <eliz@gnu.org>
Cc: spwhitton@spwhitton.name,  emacs-devel@gnu.org
Subject: Re: Is this a bug in while-let or do I missunderstand it?
Date: Sun, 24 Nov 2024 11:49:27 +0100	[thread overview]
Message-ID: <867c8ssy88.fsf@fastmail.fm> (raw)
In-Reply-To: <86o72i5ip1.fsf@fastmail.fm> (Joost Kremers's message of "Thu, 14 Nov 2024 09:21:46 +0100")

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

On Thu, Nov 14 2024, Joost Kremers wrote:
> On Thu, Nov 14 2024, Eli Zaretskii wrote:
>>> From: Joost Kremers <joostkremers@fastmail.fm>
>>> I ended up putting it in the description of the first macro (`if-let*`) and
>>> referring to it in the others, because the relevant variable (here SPEC) is
>>> actually called VARLIST in `if-let*`, `when-let*` and `and-let*`, but SPEC
>>> in while-let. (The non-starred versions also have SPEC, but they're being
>>> deprecated. BTW, any reason why `while-let` isn't called `while-let*`?)
>>
>> The disadvantage of what you did is that you need to say repeatedly
>>
>>   @var{varlist} has the same form as in @code{if-let*}.
>>
>> and the reader has to go back, read the description of if-let* (which
>> she might not want to know anything about), and decide which parts of
>> that description are relevant to whatever macro she is interested in.
>
> Okay, so I'll put the explanation of VARLIST into the description of every
> macro.
>

Here's the new patch (finally...) `when-let*`, `and-let*` and `while-let`
now have an additional paragraph saying:

```
@var{varlist} has the same form as in @code{if-let*}: Each element of
@code{varlist} has the form @w{@code{(@var{symbol} @var{value-form})}}, in
which @var{value-form} is evaluated and @var{symbol} is locally bound to
the result. Bindings are sequential, as in @code{let*} (@pxref{Local
Variables}). As a special case, @var{symbol} can be omitted if only the
test result of @var{value-form} is of interest: @var{value-form} is
evaluated and checked for @code{nil}, but its value is not bound. ```

I agree this is better when you only want to read up on a single macro, but
it's arguably less pretty when you're reading through the entire section,
having to read the same thing four times... For that case, I pointed out
that VARLIST is the same as for `if-let*`, so a reader knows they can skip
that paragraph and won't have to wonder if there are subtle differences
between the macros.

-- 
Joost Kremers
Life has its moments


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Improve-documentation-for-while-let.patch --]
[-- Type: text/x-patch, Size: 4790 bytes --]

From 5ff93bf0652cd3c409e08c4d521945c6ca60c207 Mon Sep 17 00:00:00 2001
From: Joost Kremers <joostkremers@fastmail.com>
Date: Mon, 11 Nov 2024 23:38:49 +0100
Subject: [PATCH] Improve documentation for `while-let'.

* doc/lispref/control.texi: Improve documentation for `while-let`.
---
 doc/lispref/control.texi | 64 +++++++++++++++++++++++++++++++++-------
 1 file changed, 53 insertions(+), 11 deletions(-)

diff --git a/doc/lispref/control.texi b/doc/lispref/control.texi
index 80ed2ce899b..a05e4d81fda 100644
--- a/doc/lispref/control.texi
+++ b/doc/lispref/control.texi
@@ -322,25 +322,46 @@ Conditionals
 described below.
 
 @defmac if-let* varlist then-form else-forms...
-Evaluate each binding in @var{varlist} in turn, like in @code{let*}
-(@pxref{Local Variables}), stopping if a binding value is @code{nil}.
-If all are non-@code{nil}, return the value of @var{then-form},
-otherwise the last form in @var{else-forms}.
+Evaluate each binding in @var{varlist}, stopping if a binding value is
+@code{nil}.  If all are non-@code{nil}, return the value of
+@var{then-form}, otherwise the last form in @var{else-forms}.
+
+Each element of @code{varlist} has the form @w{@code{(@var{symbol}
+@var{value-form})}}: @var{value-form} is evaluated and @var{symbol} is
+locally bound to the result.  Bindings are sequential, as in @code{let*}
+(@pxref{Local Variables}).  As a special case, @var{symbol} can be
+omitted if only the test result of @var{value-form} is of interest:
+@var{value-form} is evaluated and checked for @code{nil}, but its value
+is not bound.
 @end defmac
 
 @defmac when-let* varlist then-forms...
-Like @code{if-let*}, but without @var{else-forms}.
+Evaluate each binding in @var{varlist}, stopping if a binding value is
+@code{nil}.  If all are non-@code{nil}, return the value of the last
+form in @var{then-forms}.
+
+@var{varlist} has the same form as in @code{if-let*}: Each element of
+@code{varlist} has the form @w{@code{(@var{symbol} @var{value-form})}},
+in which @var{value-form} is evaluated and @var{symbol} is locally bound
+to the result.  Bindings are sequential, as in @code{let*} (@pxref{Local
+Variables}).  As a special case, @var{symbol} can be omitted if only the
+test result of @var{value-form} is of interest: @var{value-form} is
+evaluated and checked for @code{nil}, but its value is not bound.
 @end defmac
 
 @defmac and-let* varlist then-forms...
-Like @code{when-let*}, but in addition, if there are no
-@var{then-forms} and all the bindings evaluate to non-@code{nil}, return
+Evaluate each binding in @var{varlist}, stopping if a binding value is
+@code{nil}.  If all are non-@code{nil}, return the value of the last
+form in @var{then-forms}, or, if there are no @var{then-forms}, return
 the value of the last binding.
-@end defmac
 
-@defmac while-let spec then-forms...
-Like @code{when-let*}, but repeat until a binding in @var{spec} is
-@code{nil}.  The return value is always @code{nil}.
+@var{varlist} has the same form as in @code{if-let*}: Each element of
+@code{varlist} has the form @w{@code{(@var{symbol} @var{value-form})}},
+in which @var{value-form} is evaluated and @var{symbol} is locally bound
+to the result.  Bindings are sequential, as in @code{let*} (@pxref{Local
+Variables}).  As a special case, @var{symbol} can be omitted if only the
+test result of @var{value-form} is of interest: @var{value-form} is
+evaluated and checked for @code{nil}, but its value is not bound.
 @end defmac
 
 Some Lisp programmers follow the convention that @code{and} and
@@ -348,6 +369,27 @@ Conditionals
 @code{when} and @code{when-let*} are for forms evaluated for side-effect
 with returned values ignored.
 
+A similar macro exists to run a loop until one binding evaluates to
+@code{nil}:
+
+@defmac while-let spec then-forms...
+Evaluate each binding in @var{spec} in turn, stopping if a binding value
+is @code{nil}.  If all are non-@code{nil}, execute @var{then-forms},
+then repeat the loop.  Note that when the loop is repeated, the
+@var{value-forms} in @var{spec} are re-evaluated and the bindings are
+established anew.
+
+@var{varlist} has the same form as in @code{if-let*}: Each element of
+@code{varlist} has the form @w{@code{(@var{symbol} @var{value-form})}},
+in which {value-form} is evaluated and @var{symbol} is locally bound to
+the result.  Bindings are sequential, as in @code{let*} (@pxref{Local
+Variables}).  As a special case, @var{symbol} can be omitted if only the
+test result of @var{value-form} is of interest: @var{value-form} is
+evaluated and checked for @code{nil}, but its value is not bound.
+
+The return value of @code{while-let} is always @code{nil}.
+@end defmac
+
 @node Combining Conditions
 @section Constructs for Combining Conditions
 @cindex combining conditions
-- 
2.47.0


  parent reply	other threads:[~2024-11-24 10:49 UTC|newest]

Thread overview: 64+ 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                     ` Sv: [External] : Re: Is this a bug in while-let or do I missunderstand it? arthur miller
2024-11-09 22:36                       ` 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-20  5:32                                     ` Sean Whitton
2024-11-24 10:49                                     ` Joost Kremers [this message]
2024-11-25  4:45                                       ` Sean Whitton
2024-11-25  8:18                                         ` 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
  -- strict thread matches above, loose matches on Subject: below --
2024-11-12  3:36 arthur miller
2024-11-12  8:30 ` Joost Kremers
2024-11-12 17:55   ` Alfred M. Szmidt
2024-11-12  3:41 arthur miller

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=867c8ssy88.fsf@fastmail.fm \
    --to=joostkremers@fastmail.fm \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=spwhitton@spwhitton.name \
    /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.