GNU bug report logs - #65017
29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function

Previous Next

Full log

Message #148 received at 65017 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Alan Mackenzie <acm <at> muc.de>
Cc: Mattias Engdegård <mattias.engdegard <at> gmail.com>,
 65017 <at> debbugs.gnu.org, Eric Marsden <eric.marsden <at> risk-engineering.org>
Subject: Re: bug#65017: 29.1; Byte compiler interaction with cl-lib function
 objects, removes symbol-function
Date: Sat, 12 Aug 2023 14:28:44 -0400

> The code is substituting (function F) with a non-eq (function F).
> You're saying this has some effect in macroexp--expand-all.  I can't see
> that, yet.  All I see is FORM, (function F), being substituted by a
> different (function F) in L327 of macroexp.el.  Then there are the pcase
> arms for (function (lambda ....)) and for (function ....).  Are either
> of these pcase arms affected by the "expansion" of FORM?  If so, how?
> Or am I looking at the wrong place entirely?

`cl-flet` needs to replace (function LOCALFUN) with LOCALVAR within the
body of the let, for those LOCALFUNs defined in the `cl-flet`.
That's easy to do with a macro.

But it also should leave all other uses of `function` untouched.
That's the part that does not map well to macros since macros are
repeatedly expanded until they return something that's not a macro call.

>> It's not a function but a special operator, which is thus handled in
>> a hard-coded way by `macroexp--expand-all`.
> Is it the case that this hard-coded handling for function is prevented
> by the macro "expansion" of (function F)?

Yes, we first expand the macros and then try to handle the result
which should be one of the hard-coded cases (or is otherwise assumed to
be a function call).


        Stefan

Previous Next

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