bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects)

[Alan Mackenzie <acm@muc.de>]

Hello, Andrea.

On Sat, Jul 06, 2024 at 03:48:50 -0400, Andrea Corallo wrote:
> Alan Mackenzie <acm@muc.de> writes:

> > Hello, Stefan.

> > On Fri, Jul 05, 2024 at 14:17:38 -0400, Stefan Monnier wrote:
> >> > Not sure what you mean by "no such thing as a form ... like a closure".

> >> A form that starts with `closure` is not a valid form because there is
> >> no definition for `closure`: (fboundp 'closure) => nil.

> >> > I bumped into one last summer.

> >> > In particular (in my development repo fixing bug #64646) I put this into
> >> > *scratch*:

> >> >     (defconst foo (lambda (baz) (car baz)))

> >> > , evaluated it with C-x C-e and then M-: (native-compile foo).  This
> >> > threw the error "Cannot native-compile, form is not a lambda".

> >> That error seems right according to the docstring:

> >>    (defun native-compile (function-or-file &optional output)
> >>      "Compile FUNCTION-OR-FILE into native code.
> >>    This is the synchronous entry-point for the Emacs Lisp native
> >>    compiler.  FUNCTION-OR-FILE is a function symbol, a form, or the
> >>    filename of an Emacs Lisp source file.  If OUTPUT is non-nil, use
> >>    it as the filename for the compiled object.  If FUNCTION-OR-FILE
> >>    is a filename, if the compilation was successful return the
> >>    filename of the compiled object.  If FUNCTION-OR-FILE is a
> >>    function symbol or a form, if the compilation was successful
> >>    return the compiled function."

> >> (closure ...) is not a function symbol nor a valid form.  Instead it's
> >> a function value and the docstring doesn't say such are
> >> a valid arguments to `native-compile`.

> > All very clever arguments, no doubt, but in the end it means you cannot
> > native compile foo.  I've just tried it on emacs-30, and it doesn't work.
> > But you could compile foo last summer after my fixes for bug #64646.
> > Between last summer and now, something has gone badly wrong in Emacs's
> > basic mechanisms.

> (defconst foo (lambda (baz) (car baz)))                                                                                                                                           
> (native-compile #'foo)

> Never worked AFAIR, ....

No.  But (native-compile foo) did work.  It compiled the value of foo,
producing an anonymous subr.

> ....the functionality you added was:

> (defun foo () "foo doc string"
>        (lambda () "lambda doc string" 3))

> (subr-native-elisp-p (funcall (native-compile 'foo)))

Yes.

> And this still works for me.

It still works for me, too.

> I'm probably missing something sorry.

The fact that

	(defconst foo (lambda (baz) (car baz)))
	(native-compile foo)

worked (as of 2023-11-08), but no longer does.  It was not the main topic
of bug #64646 (for which see above), but was fixed in the commit for that
bug anyway.  This was possibly not a good idea.  That commit was:

commit 06e4ebc81a44c709b08ce72c746629c6c77e6f6e
Author: Alan Mackenzie <acm@muc.de>
Date:   Wed Nov 8 20:49:48 2023 +0000

    With `native-compile', compile lambdas in a defun or lambda too

..

>   Andrea

-- 
Alan Mackenzie (Nuremberg, Germany).