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

[Alan Mackenzie]

Hello, Stefan.

On Fri, Jul 05, 2024 at 16:26:02 -0400, Stefan Monnier wrote:
> >> (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.

> To obey the docstring, ....

Forget that doc string, just do what is right, expected, and convenient
for Emacs users, and adjust the doc string afterwards.

> > I've just tried it on emacs-30, and it doesn't work.

> As it is allowed to, according to its docstring.

Forget that doc string.  It belongs to lawyers, not reality.

> > But you could compile foo last summer after my fixes for bug #64646.

> [ But that still failed to make it work for byte-compiled function values,
>   and it failed to update the docstring to announce that new behavior.  ]

That is a strawman.  You have never been able to compile from
byte-compiled code to native compiled code, and never will (unless
Andrea has anything new to the contrary to say).  

The point is being able to compile foo, from read source code.  You
don't want to be able to do this for reasons I can't fathom.

> >> Admittedly, maybe we should extend `native-compile` to accept function
> >> values, just like `byte-compile`.
> > Or something like that, yes.  But if logical combinations of terms like
> > "form", "closure", "function value", "valid form" lead to not being able
> > to compile foo, then I suggest that these terms and their applicability
> > might need to be thought through somewhat.

> Don't worry: they've been thought through aplenty.

Clearly not.  The confusion they're apparently causing is affecting Emacs.

> >>> So I fixed comp--spill-lap-function (form version) so as to compile
> >>> that form.
> >> Why `comp--spill-lap-function` specifically (instead of
> >> `native-compile`, for example)?
> > I fixed what was wrong at the time.

> I'd like to implement the feature of `native-compile` accepting function
> values correctly rather than in the most expedient way.  If you could
> try to remember why you fixed it in this specific way, ....

I have no records of my reasons.  Having diagnosed the problem, it was
not difficult to fix.  I just fixed it in the simplest, most obvious,
and most obviously correct way.

> .... that would be very helpful, because I'm not sufficiently familiar
> with the code of `comp--spill-lap-function` to be sure of what I'm
> doing.

> >> > I've no idea how Emacs would handle that defconst now.
> >> Hmm... AFAICT your example doesn't relate to `defconst`.
> >> You'd get the same result with
> >>     M-: (native-compile (lambda (baz) (car baz))) RET
> > Whatever.  foo doesn't compile; that should be fixed.

> All I'm saying is that it's a feature request, rather than a bug to
> be fixed.

Functionality has been lost.  Finding an excuse in the exact meaning of
words rarely used with such precision is not a way to restore that
functionality.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).