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

Previous Next

Package: emacs;

Reported by: Eric Marsden <eric.marsden <at> risk-engineering.org>

Date: Wed, 2 Aug 2023 13:34:02 UTC

Severity: normal

Found in version 29.1

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

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: Mon, 14 Aug 2023 17:10:17 +0000
Hello, Stefan.

On Sun, Aug 13, 2023 at 12:12:02 -0400, Stefan Monnier wrote:
> > Thanks, that's useful information.  But it doesn't address my questions
> > in the slightest.

> I'm sorry.  I guess I still haven't figured what it is that I assume as
> known but which you don't actually know.

I didn't, and don't know the answers to the questions I asked.

> > Would you please answer these specific questions, now, to help me
> > understand this difficult mechanism.  Thanks!

> [ I assume you're talking about the questions below.  ]

I was actually talking about those strings of characters which I had
terminated with the '?' character.  All you've done with them is to snip
them from your reply.  I'm not going to ask you a fourth time.  You
clearly don't want to answer these questions, for some reason.

Maybe I'll get around to working out for myself how this code works,
maybe I won't.  But if it's up to me to fix the broken commenting/doc
strings associated with cl--labels-convert, it's not looking like it'll
get done any time soon.

Thnks for the answers that you did give me, below.

> >> >> 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).
> > Are you talking about the code in macroexp--expand-all, here?

> Yes.

> > By "macros", do you mean cl-flet and cl-labels here (as opposed to
> > function)?

> I'm talking about any call to an identifier that is "currently" defined
> as a macro.  This can be either because the `symbol-function` holds
> something of the form `(macro . <DEF>)` or because
> `macroexpand-all-environment` has an entry for that identifier.

> > What do you mean by "hard-coded cases"?

> The face that `macroexp--expand-all` handles the `function` identifier
> as follows:

>           (pcase form
>             [...]
>             (`(,(or 'function 'quote) . ,_) form)
>             [...]


> -- Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).




This bug report was last modified 1 year and 337 days ago.

Previous Next


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