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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56875 in the body.
You can then email your comments to 56875 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; [PATCH] Add thread-as macro
Date: Mon, 01 Aug 2022 19:06:53 +0200

[Message part 1 (text/plain, inline)]

It has been noted many times that threading macros are not as useful in
Emacs Lisp because the APIs are not always consistent with regard to the
ordering of arguments.  A “thread-as” macro on the lines of Clojure's
'as->' [1] would address this difficulty.

The signature of the Clojure macro is (as-> expr name & forms), which
looks a bit odd to me.  Here I've changed this so the lexical variable
(name) comes before the initial value (expr).

Also, unlike thread-first and thread-last, in the attached version of
the macro there's no magic whereby an element of FORMS which is a
symbol, say fun, is turned into a function call, i.e. (fun name).  In
other words, (thread-as x 1 1+) returns the symbol 1+.  Clojure
behaves the same.  I'm not necessarily against changing the macro so
that the above example returns 2, but I don't see a good reason to do
so either; for one thing, the example gives a byte-compilation warning
(unused lexical variable x).

[1]: https://clojure.github.io/clojure/clojure.core-api.html#clojure.core/as-%3E

[0001-Add-thread-as-macro.patch (text/x-patch, attachment)]

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

From: Richard Stallman <rms <at> gnu.org>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 56875 <at> debbugs.gnu.org
Subject: Re: bug#56875: 29.0.50; [PATCH] Add thread-as macro
Date: Mon, 01 Aug 2022 23:40:53 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Clojure is not really much like Lisp.  Would you please write down the
specs of the construct that you propose we add?  Please make it
self-contained, not assuming any knowledge of Clojure.  We will need that text
as the basis to document it for the Emacs Lisp Reference Manual.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Richard Stallman <rms <at> gnu.org>
Cc: 56875 <at> debbugs.gnu.org
Subject: Re: bug#56875: 29.0.50; [PATCH] Add thread-as macro
Date: Tue, 02 Aug 2022 08:57:21 +0200

On Mon,  1 Aug 2022 at 23:40, Richard Stallman <rms <at> gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> Clojure is not really much like Lisp.  Would you please write down the
> specs of the construct that you propose we add?  Please make it
> self-contained, not assuming any knowledge of Clojure.  We will need that text
> as the basis to document it for the Emacs Lisp Reference Manual.

Did you see the patch attached to my first message?

Concerning documentation, I wrote a docstring with the same level of
detail of the existing thread-first and thread-last, which is on the
terse side but probably sufficient.  WDYT?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 56875 <at> debbugs.gnu.org, 'Eli Zaretskii' <eliz <at> gnu.org>
Subject: Re: bug#56875: 29.0.50; [PATCH] Add thread-as macro
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?

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.

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

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

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

>> 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).

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.)

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

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

> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>,  56875 <at> debbugs.gnu.org
> Date: Tue, 02 Aug 2022 14:56:02 +0200
> 
> 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

How frequent that is, and why do you thing using the proposed syntax
makes it less awkward?

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

From: Richard Stallman <rms <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56875 <at> debbugs.gnu.org, eliz <at> gnu.org, arstoffel <at> gmail.com
Subject: Re: bug#56875: 29.0.50; [PATCH] Add thread-as macro
Date: Tue, 02 Aug 2022 23:47:08 -0400

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

 > +     (thread-as x
 > +       4
 > +       (- 10 x)
 > +       (/ x 2))

I propose a different syntax which is more Lispy than thread-as, and
more self-evident:

(let-successive ((x 4
                    (- 10 x)))
  (/ x 2))

A Lisper can guess what it means, without having read a description.

It lends itself to a generalization where there is more than
one bound variable, each of which can have several values:

(let-successive ((x 4
                    (- 10 x))
                 (y 6
                    (- 12 y)))
  (* x y))
 => 36

The values after the first can refer to all of the variables,
since all of them are already bound (to the previous values)
at that point.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: Richard Stallman <rms <at> gnu.org>
Cc: 56875 <at> debbugs.gnu.org, Lars Ingebrigtsen <larsi <at> gnus.org>, eliz <at> gnu.org
Subject: Re: bug#56875: 29.0.50; [PATCH] Add thread-as macro
Date: Fri, 05 Aug 2022 09:44:50 +0200

On Tue,  2 Aug 2022 at 23:47, Richard Stallman <rms <at> gnu.org> wrote:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>  > +     (thread-as x
>  > +       4
>  > +       (- 10 x)
>  > +       (/ x 2))
>
> I propose a different syntax which is more Lispy than thread-as, and
> more self-evident:
>
> (let-successive ((x 4
>                     (- 10 x)))
>   (/ x 2))
>
> A Lisper can guess what it means, without having read a description.
>
> It lends itself to a generalization where there is more than
> one bound variable, each of which can have several values:
>
> (let-successive ((x 4
>                     (- 10 x))
>                  (y 6
>                     (- 12 y)))
>   (* x y))
>  => 36
>
> The values after the first can refer to all of the variables,
> since all of them are already bound (to the previous values)
> at that point.

This is an interesting alternative.  I'd suggest to wait for other
opinions about the need for this kind of macro in general, and which
variant is preferred.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 56875 <at> debbugs.gnu.org, eliz <at> gnu.org, Richard Stallman <rms <at> gnu.org>
Subject: Re: bug#56875: 29.0.50; [PATCH] Add thread-as macro
Date: Fri, 02 Sep 2022 12:46:15 +0200

Augusto Stoffel <arstoffel <at> gmail.com> writes:

> This is an interesting alternative.  I'd suggest to wait for other
> opinions about the need for this kind of macro in general, and which
> variant is preferred.

I think the conclusion here is that there's not much enthusiasm for
adding thread-as, and adding a more Lisp-like version like Richard
proposes wouldn't satisfy anybody, I think: People coming from a Lisp
background generally like writing Lisp in the order they're used to, and
people who like the reversed order want something less Lispy.

So I'm closing this bug report.

Previous Next

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