GNU bug report logs - #76413
[PATCH] New macro 'compf' for composing functions

Previous Next

To reply to this bug, email your comments to 76413 AT debbugs.gnu.org.

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

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] New macro 'compf' for composing functions
Date: Wed, 19 Feb 2025 14:52:11 +0100

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

Tags: patch

This patch adds a new macro 'compf' that streamlines the common pattern
of function composition.

Namely, instead of (lambda (x) (foo (bar (baz x)))), with this macro we
can write (compf foo bar baz), which expands to exactly the same form.

This is similar in essence to the "compose" function proposed in
https://lists.gnu.org/archive/html/emacs-devel/2021-02/msg01138.html
with the main difference that compf is a macro, not a function, so it
incurs no runtime performance penalty.

There are many occurrences of function composition in the Emacs code
base alone that can be simplified with this macro.  For example:

- In lisp/calc/calc-mode.el:
  (lambda (v) (symbol-value (car v)))       => (compf symbol-value car)
- In lisp/dired-aux.el:
  (lambda (dir) (not (file-remote-p dir)))  => (compf not file-remote-p)
- In lisp/env.el:
  (lambda (var) (getenv (upcase var)))      => (compf getenv upcase)
- In lisp/mail/smtpmail.el:
  (lambda (s) (intern (downcase s)))        => (compf intern downcase)
- In lisp/net/tramp-container.el:
  (lambda (line) (car (split-string line))) => (compf car split-line)
- ...


Best,

Eshel

[0001-New-macro-compf-for-composing-functions.patch (text/patch, attachment)]

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>
Cc: Eshel Yaron <me <at> eshelyaron.com>, 76413 <at> debbugs.gnu.org
Subject: Re: bug#76413: [PATCH] New macro 'compf' for composing functions
Date: Wed, 19 Feb 2025 15:34:40 +0100

Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

Hi Eshel,

> This patch adds a new macro 'compf' that streamlines the common pattern
> of function composition.

I have no opinion about this change. However,

> - In lisp/net/tramp-container.el:
>   (lambda (line) (car (split-string line))) => (compf car split-line)

Pls don't touch Tramp. It is backwards compatible down to Emacs 28.

> Best,
>
> Eshel

Best regards, Michael.

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: "Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text
 editors" <bug-gnu-emacs <at> gnu.org>, 76413 <at> debbugs.gnu.org
Subject: Re: bug#76413: [PATCH] New macro 'compf' for composing functions
Date: Wed, 19 Feb 2025 16:10:08 +0100

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

Hi Michael,

Michael Albinus <michael.albinus <at> gmx.de> writes:

> Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs <at> gnu.org> writes:
>
> Hi Eshel,
>
>> This patch adds a new macro 'compf' that streamlines the common pattern
>> of function composition.
>
> I have no opinion about this change. However,
>
>> - In lisp/net/tramp-container.el:
>>   (lambda (line) (car (split-string line))) => (compf car split-line)
>
> Pls don't touch Tramp. It is backwards compatible down to Emacs 28.

Noted.  To be clear, I'm not proposing to change any existing code at
this point, only to add the new macro.

Anyway, here's an updated patch, which improves the macro's hygiene and
fixes a typo in the docstring:

[v2-0001-New-macro-compf-for-composing-functions.patch (text/x-patch, inline)]

From e2834b162f3f1fa1c8dc8e057e3aa00950269d8e Mon Sep 17 00:00:00 2001
From: Eshel Yaron <me <at> eshelyaron.com>
Date: Wed, 19 Feb 2025 12:58:40 +0100
Subject: [PATCH v2] New macro 'compf' for composing functions

* lisp/subr.el (compf): New macro.  (Bug#76413)
---
 lisp/subr.el | 33 +++++++++++++++++++++++++++++++++
 1 file changed, 33 insertions(+)

diff --git a/lisp/subr.el b/lisp/subr.el
index e9b49ae5376..d1615c9083f 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -7678,4 +7678,37 @@ internal--c-header-file-path
                   base
                 (append base (list (expand-file-name arch "/usr/include"))))))))))
 
+(defmacro compf (&rest funs)
+  "Expand to the function composition of FUNS, outermost function first.
+
+For example, (compf car cdr) expands to (lambda (x) (car (cdr x))),
+which does the same as `cadr'.
+
+FUNS may contain symbols which refer to functions, such as `car' and
+`cdr' in the example above, and it can also contain `lambda' functions
+and other forms which evaluate to function values.  To refer to a local
+variable VAR that is bound to a function, wrap VAR in a vector, as in:
+
+  (let ((foo (lambda (...) ...)))
+    (compf ignore [foo] always))
+
+If FUNS is empty, expand to `identity'."
+  (cond
+   ((null funs) '#'identity)
+   ((length= funs 1)
+    (let ((fun (car funs)))
+      (cond
+       ((symbolp fun) `#',fun)          ; Function name.
+       ((vectorp fun) (aref fun 0))     ; Local variable reference.
+       (t fun))))                       ; `lambda' and other forms.
+   (t
+    (let* ((x (gensym "x")) (arg x))
+      (dolist (fun (reverse funs))
+        (setq arg
+              (cond
+               ((symbolp fun) `(,fun ,arg))
+               ((vectorp fun) `(funcall ,(aref fun 0) ,arg))
+               (t `(funcall ,fun ,arg)))))
+      `(lambda (,x) ,arg)))))
+
 ;;; subr.el ends here
-- 
2.46.2

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

From: "Basil L. Contovounesios" <basil <at> contovou.net>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: Michael Albinus <michael.albinus <at> gmx.de>, 76413 <at> debbugs.gnu.org
Subject: Re: bug#76413: [PATCH] New macro 'compf' for composing functions
Date: Wed, 19 Feb 2025 18:13:03 +0100

Eshel Yaron [2025-02-19 16:10 +0100] wrote:

> From e2834b162f3f1fa1c8dc8e057e3aa00950269d8e Mon Sep 17 00:00:00 2001
> From: Eshel Yaron <me <at> eshelyaron.com>
> Date: Wed, 19 Feb 2025 12:58:40 +0100
> Subject: [PATCH v2] New macro 'compf' for composing functions

Nice.

> +FUNS may contain symbols which refer to functions, such as `car' and
> +`cdr' in the example above, and it can also contain `lambda' functions
> +and other forms which evaluate to function values.

A (declare (debug ...)) property would be nice, particularly for
stepping through the latter types of argument.

>  To refer to a local
> +variable VAR that is bound to a function, wrap VAR in a vector, as in:
> +
> +  (let ((foo (lambda (...) ...)))
> +    (compf ignore [foo] always))

Is there precedent for this [syntax] somewhere?

I understand that function symbols may be needed more frequently than
variable symbols in arguments to compf, but did you consider
distinguishing between the two kinds of symbol by #'-quoting function
symbols, and leaving variables unquoted?
AFAIK this has more precedents in Elisp.

> +    (let* ((x (gensym "x")) (arg x))
> +      (dolist (fun (reverse funs))
> +        (setq arg
> +              (cond
> +               ((symbolp fun) `(,fun ,arg))
> +               ((vectorp fun) `(funcall ,(aref fun 0) ,arg))
> +               (t `(funcall ,fun ,arg)))))
> +      `(lambda (,x) ,arg)))))

I wonder if we could/should be smart™ about the func-arity of the
rightmost function and adapt the wrapper lambda's arglist accordingly.

Finally, would you like to write an announcement and some tests as well?

Thanks,
-- 
Basil

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eshel Yaron <me <at> eshelyaron.com>, 76413 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#76413: [PATCH] New macro 'compf' for composing functions
Date: Wed, 19 Feb 2025 10:36:27 -0800

Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> This patch adds a new macro 'compf' that streamlines the common pattern
> of function composition.
>
> Namely, instead of (lambda (x) (foo (bar (baz x)))), with this macro we
> can write (compf foo bar baz), which expands to exactly the same form.
>
> This is similar in essence to the "compose" function proposed in
> https://lists.gnu.org/archive/html/emacs-devel/2021-02/msg01138.html
> with the main difference that compf is a macro, not a function, so it
> incurs no runtime performance penalty.
>
> There are many occurrences of function composition in the Emacs code
> base alone that can be simplified with this macro.  For example:
>
> - In lisp/calc/calc-mode.el:
>   (lambda (v) (symbol-value (car v)))       => (compf symbol-value car)
> - In lisp/dired-aux.el:
>   (lambda (dir) (not (file-remote-p dir)))  => (compf not file-remote-p)
> - In lisp/env.el:
>   (lambda (var) (getenv (upcase var)))      => (compf getenv upcase)
> - In lisp/mail/smtpmail.el:
>   (lambda (s) (intern (downcase s)))        => (compf intern downcase)
> - In lisp/net/tramp-container.el:
>   (lambda (line) (car (split-string line))) => (compf car split-line)
> - ...

I'm copying in Stefan Monnier.

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eshel Yaron <me <at> eshelyaron.com>, 76413 <at> debbugs.gnu.org
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#76413: [PATCH] New macro 'compf' for composing functions
Date: Wed, 19 Feb 2025 10:40:01 -0800

Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> Tags: patch
>
> This patch adds a new macro 'compf' that streamlines the common pattern
> of function composition.
>
> Namely, instead of (lambda (x) (foo (bar (baz x)))), with this macro we
> can write (compf foo bar baz), which expands to exactly the same form.
>
> This is similar in essence to the "compose" function proposed in
> https://lists.gnu.org/archive/html/emacs-devel/2021-02/msg01138.html
> with the main difference that compf is a macro, not a function, so it
> incurs no runtime performance penalty.
>
> There are many occurrences of function composition in the Emacs code
> base alone that can be simplified with this macro.  For example:
>
> - In lisp/calc/calc-mode.el:
>   (lambda (v) (symbol-value (car v)))       => (compf symbol-value car)
> - In lisp/dired-aux.el:
>   (lambda (dir) (not (file-remote-p dir)))  => (compf not file-remote-p)
> - In lisp/env.el:
>   (lambda (var) (getenv (upcase var)))      => (compf getenv upcase)
> - In lisp/mail/smtpmail.el:
>   (lambda (s) (intern (downcase s)))        => (compf intern downcase)
> - In lisp/net/tramp-container.el:
>   (lambda (line) (car (split-string line))) => (compf car split-line)
> - ...

Why not name it `compose` as in CL and ELisp?

How about a function with a compiler macro?

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: "Basil L. Contovounesios" <basil <at> contovou.net>
Cc: Michael Albinus <michael.albinus <at> gmx.de>, 76413 <at> debbugs.gnu.org
Subject: Re: bug#76413: [PATCH] New macro 'compf' for composing functions
Date: Wed, 19 Feb 2025 19:46:39 +0100

Hi,

"Basil L. Contovounesios" <basil <at> contovou.net> writes:

> Eshel Yaron [2025-02-19 16:10 +0100] wrote:
>
>> From e2834b162f3f1fa1c8dc8e057e3aa00950269d8e Mon Sep 17 00:00:00 2001
>> From: Eshel Yaron <me <at> eshelyaron.com>
>> Date: Wed, 19 Feb 2025 12:58:40 +0100
>> Subject: [PATCH v2] New macro 'compf' for composing functions
>
> Nice.
>
>> +FUNS may contain symbols which refer to functions, such as `car' and
>> +`cdr' in the example above, and it can also contain `lambda' functions
>> +and other forms which evaluate to function values.
>
> A (declare (debug ...)) property would be nice, particularly for
> stepping through the latter types of argument.

Oh, good idea...  The following spec seems to work well, but I'm not
that experienced with Edebug specs, so improvement suggestions would be
very welcome:

  (declare (debug (&rest &or symbolp vectorp lambda-expr form)))

>>  To refer to a local
>> +variable VAR that is bound to a function, wrap VAR in a vector, as in:
>> +
>> +  (let ((foo (lambda (...) ...)))
>> +    (compf ignore [foo] always))
>
> Is there precedent for this [syntax] somewhere?

Not that I know of.

> I understand that function symbols may be needed more frequently than
> variable symbols in arguments to compf,

Indeed, that's the use case I'm optimizing for.

> but did you consider distinguishing between the two kinds of symbol by
> #'-quoting function symbols, and leaving variables unquoted?  AFAIK
> this has more precedents in Elisp.

I have considered and tried it, and I found that alternative slightly
more cumbersome.  It's nice to be able to pass function names unquoted.
Of course I'm open to reconsider if people have a strong preference.

The way I see it, it's important to support local variables for the sake
of flexibility, but it's more of a niche use case, so it's OK if
specifying a local variable requires a bit more effort, compared to a
named function.

>> +    (let* ((x (gensym "x")) (arg x))
>> +      (dolist (fun (reverse funs))
>> +        (setq arg
>> +              (cond
>> +               ((symbolp fun) `(,fun ,arg))
>> +               ((vectorp fun) `(funcall ,(aref fun 0) ,arg))
>> +               (t `(funcall ,fun ,arg)))))
>> +      `(lambda (,x) ,arg)))))
>
> I wonder if we could/should be smart™ about the func-arity of the
> rightmost function and adapt the wrapper lambda's arglist accordingly.

Perhaps, could be interesting if we could do it reliably.

> Finally, would you like to write an announcement and some tests as well?

Sure, if there no objections to this addition, I'll some tests and docs.


Eshel

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 76413 <at> debbugs.gnu.org
Subject: Re: bug#76413: [PATCH] New macro 'compf' for composing functions
Date: Wed, 19 Feb 2025 20:00:14 +0100

Hi Stefan,

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text
> editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> Tags: patch
>>
>> This patch adds a new macro 'compf' that streamlines the common pattern
>> of function composition.
>>
>> Namely, instead of (lambda (x) (foo (bar (baz x)))), with this macro we
>> can write (compf foo bar baz), which expands to exactly the same form.
>
> Why not name it `compose` as in CL and ELisp?

It's a slightly different construct then Common Lisp's compose, so I
feel like calling it by that name could lead to wrong expectations.
Another option is fcomp instead of compf, BTW, if that seems better.

> How about a function with a compiler macro?

That's a valid alternative, but it'd require quoting function names,
which is slightly less concise/convenient.

Do you see a clear advantage for using a function in this case?


Thanks,

Eshel

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 76413 <at> debbugs.gnu.org
Subject: Re: bug#76413: [PATCH] New macro 'compf' for composing functions
Date: Sun, 23 Feb 2025 00:13:45 +0000

Eshel Yaron <me <at> eshelyaron.com> writes:

>> Why not name it `compose` as in CL and ELisp?
>
> It's a slightly different construct then Common Lisp's compose, so I
> feel like calling it by that name could lead to wrong expectations.
> Another option is fcomp instead of compf, BTW, if that seems better.

If it is different, then I agree that a different name is in probably in
order.  But see below.

>> How about a function with a compiler macro?
>
> That's a valid alternative, but it'd require quoting function names,
> which is slightly less concise/convenient.
>
> Do you see a clear advantage for using a function in this case?

It's slightly less typing, but also risks being more unclear, as it has
different evaluation rules.  The name `compf` is similarly fine, but to
me comes off as a little bit cryptic.

I think allowing function names to be in variables is also more general
and thus flexible, for instance supporting things like:

    (let ((fun #'some-function))
      (mapcar (compose #'not fun) some-list))

I also forgot to say thanks for digging up the old thread and this idea.
It had completely fallen off my radar.

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 76413 <at> debbugs.gnu.org
Subject: Re: bug#76413: [PATCH] New macro 'compf' for composing functions
Date: Sun, 23 Feb 2025 07:48:50 +0100

Hi,

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Eshel Yaron <me <at> eshelyaron.com> writes:
>
>>> Why not name it `compose` as in CL and ELisp?
>>
>> It's a slightly different construct then Common Lisp's compose, so I
>> feel like calling it by that name could lead to wrong expectations.
>> Another option is fcomp instead of compf, BTW, if that seems better.
>
> If it is different, then I agree that a different name is in probably in
> order.  But see below.
>
>>> How about a function with a compiler macro?
>>
>> That's a valid alternative, but it'd require quoting function names,
>> which is slightly less concise/convenient.
>>
>> Do you see a clear advantage for using a function in this case?
>
> It's slightly less typing, but also risks being more unclear, as it has
> different evaluation rules.  The name `compf` is similarly fine, but to
> me comes off as a little bit cryptic.

I think it strikes a good balance between being concise and being
cryptic, like "incf" does.  But naming things is hard...

> I think allowing function names to be in variables is also more general
> and thus flexible, for instance supporting things like:
>
>     (let ((fun #'some-function))
>       (mapcar (compose #'not fun) some-list))

compf supports that use case, see the docstring.  
I think it's actually more general than the "compose" function, since it
also supports macros, such as ignore-errors:

(mapcar (compf ignore-errors read-from-string) '("foo" "bar" "baz"))

But that's an accidental benefit.  The salient difference is the ability
to pass function names unquoted.

> I also forgot to say thanks for digging up the old thread and this idea.
> It had completely fallen off my radar.

No problem,

Eshel

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 76413 <at> debbugs.gnu.org
Subject: Re: bug#76413: [PATCH] New macro 'compf' for composing functions
Date: Sun, 23 Feb 2025 15:51:09 +0000

Eshel Yaron <me <at> eshelyaron.com> writes:

> Hi,
>
> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>> Eshel Yaron <me <at> eshelyaron.com> writes:
>>
>>>> Why not name it `compose` as in CL and ELisp?
>>>
>>> It's a slightly different construct then Common Lisp's compose, so I
>>> feel like calling it by that name could lead to wrong expectations.
>>> Another option is fcomp instead of compf, BTW, if that seems better.
>>
>> If it is different, then I agree that a different name is in probably in
>> order.  But see below.
>>
>>>> How about a function with a compiler macro?
>>>
>>> That's a valid alternative, but it'd require quoting function names,
>>> which is slightly less concise/convenient.
>>>
>>> Do you see a clear advantage for using a function in this case?
>>
>> It's slightly less typing, but also risks being more unclear, as it has
>> different evaluation rules.  The name `compf` is similarly fine, but to
>> me comes off as a little bit cryptic.
>
> I think it strikes a good balance between being concise and being
> cryptic, like "incf" does.  But naming things is hard...

Sure.  It's not as clear as "compose" of course, but if we are going to
have a new name, I can't think of anything better.

>> I think allowing function names to be in variables is also more general
>> and thus flexible, for instance supporting things like:
>>
>>     (let ((fun #'some-function))
>>       (mapcar (compose #'not fun) some-list))
>
> compf supports that use case, see the docstring.
> I think it's actually more general than the "compose" function, since it
> also supports macros, such as ignore-errors:
>
> (mapcar (compf ignore-errors read-from-string) '("foo" "bar" "baz"))
>
> But that's an accidental benefit.  The salient difference is the ability
> to pass function names unquoted.

I'm not sure that this benefit is large enough to justify having a
macro, given the reduced clarity of not quoting as we do everywhere
else, and then feeling forced to rename it to the more awkward "compf"
instead of "compose".

One drawback of unquoted function names is that the byte-compiler won't
recognize them as functions, I think.  It could, but it would require
more code, making things more complicated in the process.  The same goes
for any other tooling.  Right?

So I'm asking again if it isn't easier to just have the quote?

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

From: Eshel Yaron <me <at> eshelyaron.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Stefan Monnier <monnier <at> iro.umontreal.ca>, 76413 <at> debbugs.gnu.org
Subject: Re: bug#76413: [PATCH] New macro 'compf' for composing functions
Date: Sun, 23 Feb 2025 18:05:20 +0100

Stefan Kangas <stefankangas <at> gmail.com> writes:

> Eshel Yaron <me <at> eshelyaron.com> writes:
>
>> Hi,
>>
>> Stefan Kangas <stefankangas <at> gmail.com> writes:
>>
>>> I think allowing function names to be in variables is also more general
>>> and thus flexible, for instance supporting things like:
>>>
>>>     (let ((fun #'some-function))
>>>       (mapcar (compose #'not fun) some-list))
>>
>> compf supports that use case, see the docstring.
>> I think it's actually more general than the "compose" function, since it
>> also supports macros, such as ignore-errors:
>>
>> (mapcar (compf ignore-errors read-from-string) '("foo" "bar" "baz"))
>>
>> But that's an accidental benefit.  The salient difference is the ability
>> to pass function names unquoted.
>
> I'm not sure that this benefit is large enough to justify having a
> macro, given the reduced clarity of not quoting as we do everywhere
> else,

I think it's as clear as any macro: it's obscure until the first time you
use it.  Like cl-callf, which likewise takes an unquoted function name.

> and then feeling forced to rename it to the more awkward "compf"
> instead of "compose".
>
> One drawback of unquoted function names is that the byte-compiler won't
> recognize them as functions, I think.  It could, but it would require
> more code, making things more complicated in the process.

I think the macro expands to plain nested function calls which the
byte-compiler readily recognizes optimizes.  For example, check out the
disassembly of this function:

  (defun foo (bar) (mapcar (compf not always) bar))

You also get Flymake warnings when if you use an undefined function, etc.

> The same goes for any other tooling.  Right?

It does confuse vanilla elisp-completion-at-point.  But IMO that calls for
improving such tools, not rejecting macros :)

> So I'm asking again if it isn't easier to just have the quote?

Since that'd require an additional compiler macro to match compf in terms
of performance, I'm not sure it's necessarily easier.  I tend to prefer
the macro and the unquoted function names, but it's not clear-cut, so I
won't insist.  We can close this bug and add a compose function instead if
you feel that that's better.


Eshel

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eshel Yaron <me <at> eshelyaron.com>
Cc: Stefan Kangas <stefankangas <at> gmail.com>, 76413 <at> debbugs.gnu.org
Subject: Re: bug#76413: [PATCH] New macro 'compf' for composing functions
Date: Sun, 23 Feb 2025 12:09:59 -0500

> I think it's as clear as any macro: it's obscure until the first time you
> use it.  Like cl-callf, which likewise takes an unquoted function name.

FWIW, I find that aspect of `cl-callf` annoying.
It's easier to add a `function` quote with the two-char #' than it is to
remove an implicit one, for which you need a wrapper of the form
(lambda (x) (funcall ... x))


        Stefan

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

From: Rudolf Schlatte <rudi <at> constantly.at>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#76413: [PATCH] New macro 'compf' for composing functions
Date: Mon, 24 Feb 2025 09:57:01 +0100

Eshel Yaron via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs <at> gnu.org> writes:

> Hi,
>
> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>> Eshel Yaron <me <at> eshelyaron.com> writes:
>>
>>>> Why not name it `compose` as in CL and ELisp?
>>>
>>> It's a slightly different construct then Common Lisp's compose, so I
>>> feel like calling it by that name could lead to wrong expectations.
>>> Another option is fcomp instead of compf, BTW, if that seems better.

FWIW, compose is not in the CL standard, but is contained in the
alexandria library which supplies things that "should be" in CL.  Guile
Scheme does seem to name the function compose:
https://www.gnu.org/software/guile/manual/html_node/Higher_002dOrder-Functions.html

>>
>> It's slightly less typing, but also risks being more unclear, as it has
>> different evaluation rules.  The name `compf` is similarly fine, but to
>> me comes off as a little bit cryptic.
>
> I think it strikes a good balance between being concise and being
> cryptic, like "incf" does.  But naming things is hard...

In CL, the "f" suffix is usually used for macros that modify a place: incf,
rotatef, setf, ... so compf doesn't really fit that scheme.

Previous Next

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