all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: "Mattias Engdegård" <mattias.engdegard@gmail.com>,
	65017@debbugs.gnu.org,
	"Eric Marsden" <eric.marsden@risk-engineering.org>
Subject: bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function
Date: Sun, 13 Aug 2023 10:10:30 +0000	[thread overview]
Message-ID: <ZNisFtkd0QLw0eGx@ACM> (raw)
In-Reply-To: <jwv7cq0rui0.fsf-monnier+emacs@gnu.org>

Hello, Stefan.

On Sat, Aug 12, 2023 at 14:28:44 -0400, Stefan Monnier wrote:
> >> 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?

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

Thanks, that's useful information.  But it doesn't address my questions
in the slightest.  This is the third time I'm asking you for help.  I
thought it would be quicker than figuring everything out on my own.  You
wrote the code, I think.

I don't understand how cl--labels-convert works, down at the car and cdr
level.  I'm asking you to help me, but I'm not sure how sensible it is
to carry on asking repeatedly.  I've replaced two paragraphs you snipped
from your last reply.

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

> >> 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?  By
"macros", do you mean cl-flet and cl-labels here (as opposed to
function)?  What do you mean by "hard-coded cases"?  Do you mean the
pcase arms in macroexp--expand-all?  If so, which ones?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2023-08-13 10:10 UTC|newest]

Thread overview: 51+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-02 10:28 bug#65017: 29.1; Byte compiler interaction with cl-lib function objects, removes symbol-function Eric Marsden
2023-08-03  9:39 ` Mattias Engdegård
2023-08-03 14:43   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-03 15:37     ` Mattias Engdegård
2023-08-03 16:36       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-03 16:53         ` Mattias Engdegård
2023-08-03 17:30           ` Mattias Engdegård
2023-08-03 16:43     ` Alan Mackenzie
2023-08-03 17:30       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-03 18:22         ` Alan Mackenzie
2023-08-03 21:00           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-03 21:10         ` Alan Mackenzie
2023-08-03 21:46           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-04  9:55             ` Alan Mackenzie
2023-08-05 22:45               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-04 10:14             ` Mattias Engdegård
2023-08-04 11:11               ` Alan Mackenzie
2023-08-04 13:41                 ` Mattias Engdegård
2023-08-05 22:40               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-06 10:47                 ` Mattias Engdegård
2023-08-08  2:33                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-04  5:35           ` Eli Zaretskii
2023-08-04 14:16             ` Alan Mackenzie
2023-08-05 20:22             ` Alan Mackenzie
2023-08-06  4:49               ` Eli Zaretskii
2023-08-04 13:22     ` Alan Mackenzie
2023-08-04 14:04       ` Eli Zaretskii
2023-08-04 14:49         ` Alan Mackenzie
2023-08-04 15:22           ` Eli Zaretskii
2023-08-04 16:43             ` Alan Mackenzie
2023-08-04 17:54               ` Eli Zaretskii
2023-08-05 22:58             ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-05 22:53       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-06 11:59         ` Alan Mackenzie
2023-08-08  2:44           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-08 16:56             ` Alan Mackenzie
2023-08-10  3:41               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-10 14:50                 ` Alan Mackenzie
2023-08-12  3:28                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-12  9:59                     ` Mattias Engdegård
2023-08-12 18:21                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-12 10:40                     ` Mattias Engdegård
2023-08-12 16:46                     ` Alan Mackenzie
2023-08-12 18:28                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-13 10:10                         ` Alan Mackenzie [this message]
2023-08-13 16:12                           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-14 17:10                             ` Alan Mackenzie
2023-08-03 16:11   ` Alan Mackenzie
2023-08-03 16:41     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-03 18:48       ` Alan Mackenzie
2023-08-09 12:27 ` Alan Mackenzie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZNisFtkd0QLw0eGx@ACM \
    --to=acm@muc.de \
    --cc=65017@debbugs.gnu.org \
    --cc=eric.marsden@risk-engineering.org \
    --cc=mattias.engdegard@gmail.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.