GNU bug report logs -
#77048
30.1; Macro `cl-load-time-value` malfunctioning at compile-time and runtime
Previous Next
Full log
Message #23 received at 77048 <at> debbugs.gnu.org (full text, mbox):
> I don't see that. Can you show in detail the steps you go through?
> I did put your file in ~/tmp/foo.el, then byte-compiled it, then did
>
> emacs -Q -l ~/tmp/foo
>
> then waited a little for the native compiler to kick in, and then
>
> M-x ltvt-test RET
>
> which did nothing.
> Doing that `M-x` a second time gave me the message "Test message".
> Same thing without native compilation.
>
Interestingly, I can't even byte-compile it (type `B` in Dired), only to
get the following error reported ๐ข:
Compiling file /tmp/cl-load-time-value-test.el at Wed Mar 19 01:04:46 2025
Entering directory โ/tmp/โ
In ltvt-test:
cl-load-time-value-test.el:41:4: Warning: reference to free variable
โ--cl-load-time--281โ
cl-load-time-value-test.el: Error: End of file during parsing
However, my previous way of reproducing the issue was through
`package-vc-install`, which can be successfully native-compiled.
Confirmed by checking the function's documentation:
ltvt-test is an autoloaded interactive native-comp-function in
โcl-load-time-value-test.elโ.
(ltvt-test)
Inferred type: (function nil t)
Not documented.
[back]
Yet running the command reports the following error:
Debugger entered--Lisp error: (void-variable --cl-load-time--0)
ltvt-test()
funcall-interactively(ltvt-test)
command-execute(ltvt-test record)
execute-extended-command(nil "ltvt-test" nil)
funcall-interactively(execute-extended-command nil "ltvt-test" nil)
command-execute(execute-extended-command)
> In my experience, it's always quite easy to rewrite the code without the
> use of `cl-load-time-value` by moving that code outside to some earlier
> `defconst`. So I do that because I shudder at the idea of relying on
> the hackish implementation of `cl-load-time-value`. ๐
>
> I think its main use case is in macros where you may not have the
> liberty to move the code to some earlier `defconst`, so you're stuck
> asking `cl-load-time-value` to do it for you.
You're right, but just like this special form is used in Common Lisp,
it's very convenient to wrap a form in `load-time-value` in place to
avoid some repeat evaluations during multiple calls. Perhaps for my
example, I should indeed use `defconst`, while using `eval-when-compile`
for other cases that do not involve function calls in the same file.
This bug report was last modified 90 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.