bug#54079: 29.0.50; Method dispatching eratically fails

[Alan Mackenzie]

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