GNU bug report logs - #77048
30.1; Macro `cl-load-time-value` malfunctioning at compile-time and runtime

Previous Next

Full log

View this message in rfc822 format

From: Bohong Huang <bohonghuang <at> qq.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 77048 <at> debbugs.gnu.org
Subject: bug#77048: 30.1; Macro `cl-load-time-value` malfunctioning at compile-time and runtime
Date: Tue, 18 Mar 2025 00:58:00 +0800

> My crystal ball tells me that perhaps you're using `cl-load-time-value`
> "at toplevel" rather than within a function? 

No, actually, I am using it within a function.

> Can you show some examples of how you use `cl-load-time-value`?
> Maybe some detail may give me an idea how to go about making it work
> without making it worse.

I created a minimal package to reproduce this issue, please check that
out: https://github.com/bohonghuang/cl-load-time-value-test.git

In my test (with native compilation), simply running command `ltvt-test`
results in an error:

funcall-interactively: Symbol’s value as variable is void:
--cl-load-time--0

> Hmm... I don't quite follow: `cl-load-time-value` does not perform
> compile-time evaluation but load-time evaluation, as its name suggests.
> Maybe you could/should use `eval-when-compile` instead?

You are right. My description was inaccurate, but the general idea is
that I hope the form in `cl-load-time-value` can be evaluated before
the function is actually called, and return an object that is always
`eq`. Maybe it's due to the load-time evaluation that makes using
`cl-load-time-value` sometimes be more convenient, as it does not
require wrapping all functions in the same file as the caller on the
call chain within `eval-when-compile`, just as I provided in the example
package.

Previous Next

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