bug#70368: [PATCH] Use a dedicated type to represent interpreted-function values

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 70368@debbugs.gnu.org
> Date: Sun, 14 Apr 2024 19:03:57 -0400
> 
> >> - "soft" incompatibilities for code which tries to display the kind of
> >>   the object it receives (such as in a completion table that wants to
> >>   add an icon indicating if something is a macro, a compiled function,
> >>   etc...).  Such code will still work but may display less informative
> >>   info because it may fail to recognize the new objects as being
> >>   interpreted functions.
> >> - "real" incompatibilities for code which digs inside the
> >>   entrails of functions to try and extract specific information.
> >>   This may fail when faced with the new interpreted functions
> >>   but should be easy to fix.
> >>   As long as such code only tries to extract info and does it via
> >>   `help-function-arglist`, `documentation`, and `interactive-form`,
> >>   there's no problem, but some packages may use code inherited from
> >>   a long time ago when `help-function-arglist` didn't exist, or written
> >>   by coders who didn't know better.  I know Hyperbole used to do that,
> >>   but I believe that's been fixed since.
> >> - "hard" incompatibilities for code which really digs inside the
> >>   code of functions.  `vc.el` did that a long time ago,
> >>   `kmacro.el` did as well until OClosures, and Buttercup (a NonGNU ELPA
> >>   package) did until a few months ago.  There are probably one or two
> >>   packages out there that will be affected like Buttercup would have
> >>   been.  FWIW, the Buttercup case was a mix of "hard" and "soft": it
> >>   really looked inside the code, but used that only to provide more
> >>   informative messages and had a fallback case when the code was
> >>   compiled, so it would still work OK.
> >
> > Some of the above should be in NEWS, I think, in the "incompatible
> > Lisp changes" section.
> 
> I don't really know what more I could put in there.  The entry I added
> states the actual changes and the above "two" are just
> direct consequences.

I think the only problems we need to mention are those with Lisp
programs that "dig" inside the code of functions.  I think it should
be enough to give one or two concrete examples (what internals the
offending code depended on), and tell that these techniques will no
longer work.  You mention above examples of packages that used to do
it, but that's not useful; providing specific examples of what those
packages did will explain the problems much better.

> How do you imagine a user or developer is going to make use of the
> above info?

They will realize which techniques are no longer supposed to work, and
could look into their code to try find such techniques.

> > I think this also calls for augmenting the documentation of
> > make-byte-code to the effect that it could now create closures as
> > well.
> 
> I'm not very happy documenting it, because I think it's an
> implementation accident resulting from the historical evolution of
> the code.  IOW something we may want to fix.

Then maybe a defalias with a suitable name could be the first step in
that direction?

I suggested documenting it because the name of the function no longer
describes accurately what it does, and people might be surprised to
see that it is used to create something other than byte-code.