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

Previous Next

Full log

View this message in rfc822 format

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

Hello, Stefan.

On Fri, Aug 11, 2023 at 23:28:01 -0400, Stefan Monnier wrote:

[ .... ]

> >> > 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.

I'll come up with something as soon as I understand it enough.

> > 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.

Your reply doesn't address my question.  It is not clear to me what the
IT in your previous paragraph is.  You may or may not have thought of
some alternative for IT, and previous code may have done IT differently,
but that doesn't help me understand what IT is.  What was the difficulty
in cl-labels and cl-flet for which IT and cl--labels-convert was the
solution?

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?

[ .... ]

> > 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`.

Is it the case that this hard-coded handling for function is prevented
by the macro "expansion" of (function F)?  Otherwise, what is the
relevance of this hard-coded handling to cl--labels-convert?

[ .... ]

>         Stefan

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

Previous Next

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