GNU bug report logs - #56875
29.0.50; [PATCH] Add thread-as macro

Previous Next

Full log

Message #19 received at 56875 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56875 <at> debbugs.gnu.org, arstoffel <at> gmail.com
Subject: Re: bug#56875: 29.0.50; [PATCH] Add thread-as macro
Date: Tue, 02 Aug 2022 14:24:38 +0300

> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 56875 <at> debbugs.gnu.org, "'Eli Zaretskii'" <eliz <at> gnu.org>
> Date: Tue, 02 Aug 2022 12:17:09 +0200
> 
> Augusto Stoffel <arstoffel <at> 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).
> 
> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.