GNU bug report logs - #54802
OClosure: Make `interactive-form` a generic function

Previous Next

Full log

View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 54802 <at> debbugs.gnu.org
Subject: bug#54802: OClosure: Make `interactive-form` a generic function
Date: Wed, 13 Apr 2022 15:53:58 +0800

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> `nadvice.el` needs to build commands whose interactive spec is computed.
> This currently can't be done with `lambda` (see also bug#51695 for
> a related problem) but `nadvice.el` is unaffected because it assembles
> its byte-code functions all by hand.  In order for `nadvice.el` to be
> able to use OClosures, we need to address this limitation.
>
> The patch below does it by making `interactive-form` a generic function,
> so OClosures can compute their interactive specs from their slots.
>
> Maybe it should be `call-interactively` that's turned into a generic
> function (which would also open up the possibility to do more than just
> compute the args to pass to the function, such as also printing the
> return value or things like that), but that would be a more significant
> change.
>
> While the performance of `call-interactively` and `interactive-form` are
> not critical, `commandp` is a function that is occasionally used in
> tight loops (typically when filtering completions from `obarray`) so
> I refrained from making it into a generic function, and instead I make
> it defer to `interactive-form` when we counter what looks like an OClosure.
>
> That keeps the common code as fast as before, tho it makes `commandp`
> slow(ish) when applied to interactive OClosures.
>
> Making `commandp` into a generic function would apparently slow down
> a loop like
>
>     (mapatoms (lambda (s) (if (commandp s) (cl-incf count))))
>
> by a factor around 2x or 3x, which is not the end of the world but
> doesn't seem justified.
>
> The patch below also includes a use of this new generic function by
> moving the interactive spec of kmacros from the kmacro objects
> themselves to the generic function.  The gain is that each `kmacro` is
> now 1 word smaller (negligible, in the grand scheme of things, but
> I included it for illustration and testing purposes).
>
> Any commment?  Objection?

Calling `interactive-form' in a loop is also fairly common.  For
example, I wrote some code a while back to list commands which operate
on the region, which involves running this on each interned atom:

  (defun region-command-p (command)
    "Test if COMMAND, a symbol, is a command that accepts a region."
    (and (commandp command)
         (equal (cadr (interactive-form command)) "r")))

I'm sure a 3x slowdown would be noticeable, so why does this have to be
a generic function?  Why can't we have `interactive-form' return some
field of a given OClosure object instead?

Thanks.

Previous Next

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