[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50
From: |
Alan Mackenzie |
Subject: |
bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects) |
Date: |
Fri, 5 Jul 2024 19:55:19 +0000 |
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.
> 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.
[ .... ]
> > 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'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.
> - Stefan
--
Alan Mackenzie (Nuremberg, Germany).
- bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects, Michael Heerdegen, 2024/07/04
- bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects, Stefan Monnier, 2024/07/04
- bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects, Stefan Monnier, 2024/07/04
- bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects, Michael Heerdegen, 2024/07/05
- bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects, Stefan Monnier, 2024/07/05
- bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects, Michael Heerdegen, 2024/07/05
- bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects, Eli Zaretskii, 2024/07/05
- bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects, Andrea Corallo, 2024/07/05
- Message not available
- Message not available
- Message not available
- bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects), Alan Mackenzie, 2024/07/05
- bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects), Stefan Monnier, 2024/07/05
- bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects),
Alan Mackenzie <=
- bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects), Stefan Monnier, 2024/07/05
- bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects), Alan Mackenzie, 2024/07/05
- bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects), Michael Heerdegen, 2024/07/05
- bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects), Eli Zaretskii, 2024/07/06
- bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects), Andrea Corallo, 2024/07/06
- bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects), Alan Mackenzie, 2024/07/06
- bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects), Michael Heerdegen, 2024/07/07
- bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects), Stefan Monnier, 2024/07/07
- bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects), Andrea Corallo, 2024/07/08
- bug#71934: comp--spill-lap-function and closure (wad: bug#71934: 31.0.50; edebug--called-interactively-skip vs. new fun objects), Alan Mackenzie, 2024/07/08