GNU bug report logs -
#78056
31.0.50; bug in `cl-eval-when` with symbols with positions
Previous Next
Full log
Message #11 received at 78056 <at> debbugs.gnu.org (full text, mbox):
On 2025-04-27 07:13, Stefan Monnier wrote:
>>>> (cl-typep '(foo) 'cons-car-foo)
>>>> => (invalid-function #<symbol lambda at 125>)
>>>>
>>>> Without compile in the `cl-eval-when' in `cl-deftype', there is no side effect.
>
> To fix this problem, `cl-eval-when` would need to do the same kind of
> `byte-run-strip-symbol-positions` dance as is done for
> `eval-when-compile` and `eval-and-compile`.
>
> But I suggest the patch below instead, which starts by acknowledging
> that `cl-eval-when` doesn't actually distinguish if it's used at
> top-level (it has an ugly hack which tries to do that, but only for those
> `cl-eval-when` nested inside another `cl-eval-when`, which his
> extremely rare, and even in those cases it's right only some of the
> time).
>
> So the patch throws away the ugly hack and just reduces `cl-eval-when`
> to one of `eval-when-compile`, `eval-and-compile`, `progn`, or nil.
>
> It might be worthwhile to improve our macro-expansion machinery to let
> (compiler-)macros know if they're used at top-level or not, but that's
> a larger undertaking and it will be easy to retro-fit it into this macro
> if/when we do that.
>
> Comments, objections?
I don't have enough expertise to judge the merits of this patch, but it
seems to me a very good thing to bring `cl-eval-when' back to the standard
`eval-when-compile' and `eval-and-compile' cases as much as possible, if
only to improve the consistency of the code and simplify its maintenance.
Thanks!
This bug report was last modified 49 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.