[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65017: 29.1; Byte compiler interaction with cl-lib function objects,
From: |
Stefan Monnier |
Subject: |
bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function |
Date: |
Fri, 11 Aug 2023 23:28:01 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
>> > And if, somehow, it does get used (the current code, I think), then (as
>> > you write below) the argument F will get replaced by an F with the wrong
>> > position. Am I right, here?
>> That's right.
> OK. So perhaps binding symbols-with-pos-enabled to nil around that eq
> call could be the way to go.
Indeed, that's the patch I suggested. I think it's fundamentally right,
but it doesn't work (yet) because it bumps into the optimization bug
introduced by making `eq` depend on `symbols-with-pos-enabled` :-(
>> > Why must the F get replaced by a different F? There must surely be a
>> > way, a simpler way than the current cl--labels-convert, to retain the
>> > current F (hence, not corrupting its position)?
>> There might. The current hack is the best I could come up with.
> I'm not criticising the hack, not at all! But it could be better
> commented, and the doc string for cl--labels-convert could be more
> informative.
It would help if you could send a (rough) patch showing what comment
you'd have liked to see.
> The "why" is missing - why is necessary to handle `function' as
> a macro?
I couldn't really think of any alternative for it ("it" being to
implement `cl-labels` and `cl-flet`). FWIW, the pre-cl-lib code did it
differently by duplicating `macroexp--expand-all` wholesale and then
tweaking its handling of `function` in an ad-hoc way.
BTW, there's a standard solution from Common Lisp to get rid of this
hack: implement the `&whole` macro argument.
[Macro Lambda Lists](http://clhs.lisp.se/Body/03_dd.htm)
> I think it's to inhibit the processing of `function' as function
> somewhere else, but where and why?
It's not a function but a special operator, which is thus handled in
a hard-coded way by `macroexp--expand-all`.
>> I'm not completely sure we agree yet on what is "the original bug", but
>> obviously I agree with your sentence :-)
> I meant bug #65017. I committed a fix for it yesterday using the patch
> I posted here on Sunday, and closed the bug.
FWIW my notion of "the original bug" should be fixed by the patch below
(modulo the above-mentioned optimization bug which makes the patch
ineffective).
BTW, I pushed an extended version of that patch which additionally does
what you suggested we should do (and which I claimed wouldn't work),
i.e. flush the cache (I originally couldn't see where to flush it).
I believe this does fix the original problem even in the remaining
corner cases, despite the optimization bug.
Stefan
diff --git a/lisp/emacs-lisp/cl-macs.el b/lisp/emacs-lisp/cl-macs.el
index 0a3181561bd..a405ae67691 100644
--- a/lisp/emacs-lisp/cl-macs.el
+++ b/lisp/emacs-lisp/cl-macs.el
@@ -2037,7 +2037,9 @@ cl--labels-convert
;; *after* handling `function', but we want to stop macroexpansion from
;; being applied infinitely, so we use a cache to return the exact `form'
;; being expanded even though we don't receive it.
- ((eq f (car cl--labels-convert-cache)) (cdr cl--labels-convert-cache))
+ ((let ((symbols-with-pos-enabled nil))
+ (eq f (car cl--labels-convert-cache)))
+ (cdr cl--labels-convert-cache))
(t
(let* ((found (assq f macroexpand-all-environment))
(replacement (and found
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, (continued)
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Stefan Monnier, 2023/08/05
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Stefan Monnier, 2023/08/05
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Alan Mackenzie, 2023/08/06
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Stefan Monnier, 2023/08/07
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Alan Mackenzie, 2023/08/08
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Stefan Monnier, 2023/08/09
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Alan Mackenzie, 2023/08/10
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function,
Stefan Monnier <=
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Mattias EngdegÄrd, 2023/08/12
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Stefan Monnier, 2023/08/12
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Mattias EngdegÄrd, 2023/08/12
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Alan Mackenzie, 2023/08/12
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Stefan Monnier, 2023/08/12
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Alan Mackenzie, 2023/08/13
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Stefan Monnier, 2023/08/13
- bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Alan Mackenzie, 2023/08/14
bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function, Alan Mackenzie, 2023/08/03