From: Philip Kaludercic <philipk@posteo.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 56974@debbugs.gnu.org
Subject: bug#56974: 29.0.50; Missing documentation for former subr-x macros
Date: Fri, 05 Aug 2022 09:19:32 +0000 [thread overview]
Message-ID: <87a68jjbdn.fsf@posteo.net> (raw)
In-Reply-To: <83les42lfd.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 04 Aug 2022 16:22:14 +0300")
[-- Attachment #1: Type: text/plain, Size: 727 bytes --]
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Philip Kaludercic <philipk@posteo.net>
>> Date: Thu, 04 Aug 2022 13:06:20 +0000
>>
>>
>> As far as I see, if-let, when-let, thread-first, ... were moved from
>> subr-x.el to subr.el last April (b05a103e). But there appears to be no
>> documentation in (I'd assume) lispref/controls.texi. My understanding
>> was that these macros were not documented in the Elisp manual as they
>> were just part of subr-x, as the comment in the subr-x header indicates
>>
>> ;; Do not document these functions in the lispref.
>> ;; https://lists.gnu.org/r/emacs-devel/2014-01/msg01006.html
>>
>> So should they be documented now?
>
> Yes, they should be.
How is this for a start:
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Document-if-let-if-let-when-let-and-and-let.patch --]
[-- Type: text/x-patch, Size: 2777 bytes --]
From 0d4c3f418d5dcdaa2f2f9c93b7e1fd103a310c62 Mon Sep 17 00:00:00 2001
From: Philip Kaludercic <philipk@posteo.net>
Date: Fri, 5 Aug 2022 11:18:29 +0200
Subject: [PATCH] Document if-let*, if-let, when-let* and and-let*
* control.texi (Conditionals): Add if-let*, if-let, when-let*
(Combining Conditions): Add and-let*
---
doc/lispref/control.texi | 47 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 47 insertions(+)
diff --git a/doc/lispref/control.texi b/doc/lispref/control.texi
index d4520ebdee..e7fd1bb41a 100644
--- a/doc/lispref/control.texi
+++ b/doc/lispref/control.texi
@@ -294,6 +294,46 @@ Conditionals
@end group
@end example
+During complex computations that might at any step, one can combine a
+@code{let}-block and some of the previous conditional control
+structures:
+
+@defmac if-let (bindings@dots) then &rest else@dots
+As with @code{let*}, @var{bindings} will consist of
+@code{(@var{symbol} @var{value-form})} entries that are evaluated and
+bound sequentially. If all @var{value-form} evaluate to
+non-@code{nil} values, then @var{then} is evaluated as were the case
+with a regular @code{let*} expression, with all the variables bound.
+If any @var{value-form} evaluates to @code{nil}, @var{else} is
+evaluated, without any bound variables.
+
+A binding may also optionally drop the @var{symbol}, and simplify to
+@code{(@var{value-form})} if only the test is of interest.
+
+For the sake of backwards compatibility, it is possible to write a
+single binding without a binding list:
+
+@example
+@group
+(if-let* (@var{symbol} (test)) foo bar)
+@equiv{}
+(if-let* ((@var{symbol} (test))) foo bar)
+@end group
+@end example
+@end defmac
+
+@defmac if-let* (bindings@dots) then &rest else
+@code{if-let*} is mostly equivalent to @code{if-let}, with the
+exception that the legacy @code{(if (@var{var} (test)) foo bar)}
+syntax is not permitted.
+@end defmac
+
+@defmac when-let (bindings@dots) &rest body
+As with @code{when}, if one is only interested in the case where all
+@var{bindings} are non-nil. Otherwise @var{bindings} are interpreted
+just as they are by @code{if-let*}.
+@end defmac
+
@node Combining Conditions
@section Constructs for Combining Conditions
@cindex combining conditions
@@ -428,6 +468,13 @@ Combining Conditions
Note that in contrast to @code{or}, both arguments are always evaluated.
@end defun
+@defmac and-let* (bindings@dots) &rest body
+A combination of @var{let*} and @var{and}, analogous to
+@code{when-let*}. If all @var{bindings} are non-@code{nil} and
+@var{body} is @code{nil}, then the result of the @code{and-let*} form
+will be the last value bound in @var{bindings}.
+@end defmac
+
@node Pattern-Matching Conditional
@section Pattern-Matching Conditional
@cindex pcase
--
2.37.1
next prev parent reply other threads:[~2022-08-05 9:19 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-04 13:06 bug#56974: 29.0.50; Missing documentation for former subr-x macros Philip Kaludercic
2022-08-04 13:22 ` Eli Zaretskii
2022-08-05 9:19 ` Philip Kaludercic [this message]
2022-08-05 12:01 ` Lars Ingebrigtsen
2022-08-06 1:45 ` Michael Heerdegen
2022-08-06 12:19 ` Lars Ingebrigtsen
2022-08-07 2:15 ` Michael Heerdegen
2022-08-07 12:51 ` Lars Ingebrigtsen
2022-08-09 9:10 ` Philip Kaludercic
2022-08-05 13:50 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
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=87a68jjbdn.fsf@posteo.net \
--to=philipk@posteo.net \
--cc=56974@debbugs.gnu.org \
--cc=eliz@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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
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).