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

Previous Next

Full log

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

Previous Next

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