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

[Eli Zaretskii]

> Date: Fri, 08 Apr 2022 16:33:51 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> `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?

My comment is that when you introduced OClosures, you never said that
the plan was to go over every place in Emacs where they can be used
and reimplement those places based on OClosures.  It sounds like this
is what's happening, and next we will see another round of churn of
the code we old-timers are familiar with to make it utterly unfamiliar
and dependent on stuff that needs to be carefully studied before it
can even be understood?  Including basic internals such as
interactive-form and its ilk?  All that to solve some minor issues
with nadvice, which itself is a minor feature as Emacs features go?
Doesn't that sound excessive?

I'm okay with having OClosures, yet another new feature of Emacs Lisp,
but I don't think I like seeing stuff like interactive-form rewritten
to be generics or having OClosures in general permeate our internals.
And speed is only one (important) aspect of that: I'd also like to
keep those internals easier understandable by people like myself, who
aren't and will never be CS professionals with special interest in
functional languages.  If that means bug#51695 must be solved some
other way, or even remain unsolved, I think I'd prefer that if this is
the price.

I'm sorry to sound like keeping progress from happening, but it lately
becomes more and more hard to do Emacs maintenance due to excessive
use of new features whose tricky and hard-to-debug code makes finding
the reasons for problems harder and harder.  We already have areas
where no one can suggest safe solutions for problems.  Do we really
want those areas to grow and multiply?

IMNSHO, Emacs is not a platform for programming language development,
it is mainly a platform for writing useful applications.  Let's not go
overboard with new Lisp features in a way that makes our main task
harder than it has to be.