[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#54079: 29.0.50; Method dispatching eratically fails
From: |
Alan Mackenzie |
Subject: |
bug#54079: 29.0.50; Method dispatching eratically fails |
Date: |
Wed, 9 Mar 2022 17:42:56 +0000 |
Hello, Stefan.
On Tue, Mar 08, 2022 at 16:03:12 -0500, Stefan Monnier wrote:
> >> I'd expect the reverse: strip first and then eval the result.
> >> Why should we not strip the form passed to `byte-compile-eval`?
> > It's an edge case either way, but the form being evaluated might be a
> > `byte-compile', in which case it's (much) better to leave the positions
> > in place during this operation.
> I don't understand the scenario you're thinking of.
> Are you thinking of something like `(eval-when-compile (byte-compile ...))?
Yes.
> Does that ever happen in real life?
Probably exceedingly seldomly.
What's to be gained by not catering to this unusual case? What do we
lose?
> >> Does `byte-compile-top-level` already return a stripped form of code?
> > Compiled code is always stripped, at least since the weekend!
> OK, so no need to strip, go.
> >> And why bother stripping the result of `byte-compile-eval`?
> > Because it might be the result of evaluating a defun (or defvar or
> > defconst).
> AFAIK sympos should only appear within the compiler pipeline between the
> "read" and the "emit resulting bytecode". They may be passed to various
> functions and macros along the way, but I can't think of any scenario
> where they'd end up returned by `(byte-compile-)eval`.
> > This was the situation which gave rise to the bug.
> Could you give some details about how it played out?
> [ Either here or as a comment in the code. ]
Michael byte compiled cl-generic.el. This created cl-generic.elc
correctly, but also left uncompiled forms in the function cells of the
symbols defun'd inside an eval-{when,and}-compile. These forms
contained symbols with positions.
> >> Fundamentally, `eval` should always strip before doing its job.
> > Except when what it's evaluating is a defun, defmacrro, defsubst, etc.
> Why?
Because that evaluated form might later be byte compiled, and the SWPs
will be needed for that.
> > Then it would be better to evaluate SWPs (which would work, since we're
> > inside a compilation, where enable-symbols-with-pos has been bound).
> > But here EXPANDED has been stripped before being evaluated, so I'm not
> > sure what you're saying here.
> I was suggesting to move the strip from the computation of `expanded` to
> the `eval` call.
> >> Yes, I know, it might be a bit expensive, but we should probably
> >> define a local function in `bytecomp.el` which does strip+eval and use
> >> that instead of `eval` (both here and in `byte-compile-eval`). WDYT?
> > I don't think stripping is really all that expensive. There are one or
> > two .el files in Emacs (ucs-normalize.el springs to mind) which have
> > very large lists with vectors in them, yet they don't seem noticeably to
> > slow down the Emacs build.
> So maybe we should redefine `eval` as "strip and then eval"?
Isn't `eval' already complicated enough, with lexical-binding as an
argument? Stripping SWPs is not a part of evaluation. It is something
else. eval should "do one thing and do it well".
> Stefan
--
Alan Mackenzie (Nuremberg, Germany).
- bug#54079: 29.0.50; Method dispatching eratically fails, (continued)
- bug#54079: 29.0.50; Method dispatching eratically fails, Eli Zaretskii, 2022/03/05
- bug#54079: 29.0.50; Method dispatching eratically fails, Michael Heerdegen, 2022/03/05
- bug#54079: 29.0.50; Method dispatching eratically fails, Alan Mackenzie, 2022/03/08
- bug#54079: 29.0.50; Method dispatching eratically fails, Stefan Monnier, 2022/03/08
- bug#54079: 29.0.50; Method dispatching eratically fails, Alan Mackenzie, 2022/03/08
- bug#54079: 29.0.50; Method dispatching eratically fails, Stefan Monnier, 2022/03/08
- bug#54079: 29.0.50; Method dispatching eratically fails,
Alan Mackenzie <=
- bug#54079: 29.0.50; Method dispatching eratically fails, Stefan Monnier, 2022/03/09
- bug#54079: 29.0.50; Method dispatching eratically fails, Alan Mackenzie, 2022/03/09
- bug#54079: 29.0.50; Method dispatching eratically fails, Stefan Monnier, 2022/03/09
- bug#54079: 29.0.50; Method dispatching eratically fails, Alan Mackenzie, 2022/03/11
- bug#54079: 29.0.50; Method dispatching eratically fails, Stefan Monnier, 2022/03/11
- bug#54079: 29.0.50; Method dispatching eratically fails, Alan Mackenzie, 2022/03/13
- bug#54079: 29.0.50; Method dispatching eratically fails, Stefan Monnier, 2022/03/14
- bug#54079: 29.0.50; Method dispatching eratically fails, Michael Heerdegen, 2022/03/08
- bug#54079: 29.0.50; Method dispatching eratically fails, Alan Mackenzie, 2022/03/09
- bug#54079: 29.0.50; Method dispatching eratically fails, Michael Heerdegen, 2022/03/15