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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 70368 <at> debbugs.gnu.org
Subject: bug#70368: [PATCH] Use a dedicated type to represent interpreted-function values
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).

>> > 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.

Hmm... I'll see what I can come up with,


        Stefan

Previous Next

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