bug#56875: 29.0.50; [PATCH] Add thread-as macro

[Augusto Stoffel]

On Tue,  2 Aug 2022 at 14:24, Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Lars Ingebrigtsen <larsi@gnus.org>
>> Cc: 56875@debbugs.gnu.org, "'Eli Zaretskii'" <eliz@gnu.org>
>> Date: Tue, 02 Aug 2022 12:17:09 +0200
>> 
>> Augusto Stoffel <arstoffel@gmail.com> writes:
>> 
>> > +(defmacro thread-as (var &rest forms)
>> > +  "Successively bind VAR to the result of evaluating each of the FORMS.
>> > +Return the last computed value.
>> > +
>> > +Example:
>> > +     (thread-as x
>> > +       4
>> > +       (- 10 x)
>> > +       (/ x 2))
>> > +          ⇒ 3"
>> > +  (declare (indent 1))
>> 
>> I'm not enthusiastic.  As experience with the other threading macros has
>> shown, they're neat hacks, but they're not used much in actual code
>> (because there's no culture for reading code that's formatted that way
>> in Emacs Lisp).

I agree that the threading style hasn't become popular in Emacs core.
But some users and package authors rely on it a lot.  Moreover, if 2 of
the 3 basic threading macros are already provided, it seems a bit
incongruent not to offer the third.

Matters of taste aside -- I only use threading occasionally -- I think
it can objectively turn certain really ugly constructs into something
that is at least palatable.

>> If others think that this would be useful, I won't object to adding it,
>> though.  Eli, what do you think?
>
> TBH, I tend to agree.  And I'd like to hear the rationale, to make the
> discussion more concrete.  Maybe if the reasons are good enough, I'll
> change my mind.  Just looking at the usage, it does sound a bit
> artificial.

One concrete example where thread-as would help is in the situation
outlined in the following message, specifically the point that “totally
breaks down if you want to mix in LITERAL etc”:

    https://lists.gnu.org/archive/html/emacs-devel/2021-09/msg01653.html

But since I proposed the macro, maybe I should wait and see if someone
else finds it useful, and in which situation.

(Also, for whatever little it's worth, the macro generates smaller
bytecode than the “just give up and go all imperative” alternative
mentioned in the linked message.)