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: Mon, 15 Apr 2024 08:22:10 -0400
> 
> > 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.
> 
> There's nothing very special about it: `car/cdr` on an interpreted
> function will fail because it's not represented as a list any more.
> You can still extract the various subparts with `aref`, tho.
> 
> >> 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.
> 
> The "techniques" that won't work any more are any and all accesses to
> a function via `car/cdr` (and derivatives, like `assq`), but that should
> be immediately obvious from:
> 
>     Instead of representing interpreted functions as lists that start
>     with either 'lambda' or 'closure', Emacs now represents them as
>     objects of their own 'interpreted-function' type, which is very
>     similar to 'byte-code-function' objects (the argument list,
>     docstring, and interactive forms are placed in the same slots).

So how about adding after the above just this single sentence:

  Thus code that attempts to "dig" into the internal structure of
  an interpreted function's object with the likes of 'car' or 'cdr'
  will no longer work (but 'aref' will still work to extract its
  various subparts).

> > 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.
> 
> Hmm... I'll see what I can come up with,

Thanks.