bug#23736: Add companion to apply-partially

bug#23736: Add companion to apply-partially

[Rasmus]

Hi,

Could we add an ‘apply-rpartially’ or ‘apply-partially-last’ to subr.el?
Like ‘apply-partially’, but fixing the last arguments.  This is useful for
e.g. ‘set-face-attribute’ where one might a common :inherits to many
faces, e.g.

    (mapc (apply-rpartially ’set-face-attribute :inherit ’fixed-pitch) ’(list of faces))

I have used this in my init.el,

    (defun apply-rpartially (fun &rest args)
      "Return a function that is a partial application of FUN to ARGS.
    ARGS is a list of the last N arguments to pass to FUN.  The
    result is a new function which does the same as FUN, except that
    the last N arguments are fixed at the values with which this
    function was called."
      (lambda (&rest args1)
        (apply fun (append args1 args))))

If that’s good I can prepare a patch that also has documentation.  (I
couldn’t find past discussions about such a function)

Rasmus

-- 
Don't slow down Johnny, leave the Cadillac runnin'

bug#23736: Add companion to apply-partially

[Lars Ingebrigtsen]

Rasmus <rasmus@gmx.us> writes:

> Could we add an ‘apply-rpartially’ or ‘apply-partially-last’ to subr.el?
> Like ‘apply-partially’, but fixing the last arguments.  This is useful for
> e.g. ‘set-face-attribute’ where one might a common :inherits to many
> faces, e.g.
>
>     (mapc (apply-rpartially ’set-face-attribute :inherit ’fixed-pitch) ’(list of faces))
>
> I have used this in my init.el,
>
>     (defun apply-rpartially (fun &rest args)
>       "Return a function that is a partial application of FUN to ARGS.
>     ARGS is a list of the last N arguments to pass to FUN.  The
>     result is a new function which does the same as FUN, except that
>     the last N arguments are fixed at the values with which this
>     function was called."
>       (lambda (&rest args1)
>         (apply fun (append args1 args))))

(I'm going through old Emacs bug reports that haven't received any
response.)

I think this sounds like a slightly too obscure function to add to Emacs
core.  apply-partially is more useful because functions are often
constructed in ways that makes that a convenient function, while the
opposite order is more unusual, I think?

(And especially with lexical support doing this sort of thing is often
easier, anyway.)

So I'm closing this as a "wontfix".

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#23736: Add companion to apply-partially

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Rasmus <rasmus@gmx.us> writes:
>
>> Could we add an ‘apply-rpartially’ or ‘apply-partially-last’ to subr.el?
>> Like ‘apply-partially’, but fixing the last arguments.  This is useful for
>> e.g. ‘set-face-attribute’ where one might a common :inherits to many
>> faces, e.g.
>>
>>     (mapc (apply-rpartially ’set-face-attribute :inherit ’fixed-pitch) ’(list of faces))
>>
>> I have used this in my init.el,
>>
>>     (defun apply-rpartially (fun &rest args)
>>       "Return a function that is a partial application of FUN to ARGS.
>>     ARGS is a list of the last N arguments to pass to FUN.  The
>>     result is a new function which does the same as FUN, except that
>>     the last N arguments are fixed at the values with which this
>>     function was called."
>>       (lambda (&rest args1)
>>         (apply fun (append args1 args))))
>
> (I'm going through old Emacs bug reports that haven't received any
> response.)
>
> I think this sounds like a slightly too obscure function to add to Emacs
> core.  apply-partially is more useful because functions are often
> constructed in ways that makes that a convenient function, while the
> opposite order is more unusual, I think?

Indeed I think partial application from the right is not as generally
useful in languages with variadic functions.  IME it is often replaced
with shorthand for closures or currying from the right.

In the case of Elisp there is also the issue that apply-partially is
both a little verbose and (currently) significantly less efficient than
an open-coded closure.

-- 
Basil