unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Michael Heerdegen <michael_heerdegen@web.de>,
	Lars Ingebrigtsen <larsi@gnus.org>,
	54079@debbugs.gnu.org
Subject: bug#54079: 29.0.50; Method dispatching eratically fails
Date: Sun, 13 Mar 2022 16:49:58 +0000	[thread overview]
Message-ID: <Yi4gtl9CfzJsJRfA@ACM> (raw)
In-Reply-To: <jwv8rtfygic.fsf-monnier+emacs@gnu.org>

Hello, Stefan.

On Fri, Mar 11, 2022 at 23:23:50 -0500, Stefan Monnier wrote:

[ .... ]

> Whatever appears in the code passed through `eval-{when,and}-compile`
> can survive that code, so the fact that `symbols-with-pos-enabled` is

> `eval` is exactly this "as long as possible" point where we know the
> code won't be compiled because it's about to be interpreted.
> non-nil while evaluating it doesn't make it correct.

OK, you've persuaded me.  ;-)  Lisp forms need to be stripped of SWPs
before being passed into `eval'.

> > But, looking at the code, I don't think byte-compile binds
> > symbols-with-pos-enabled to t.  This could be a bug.

> Maybe not: it has no reason to presume that its argument has positions.

More to the point, I don't think it can assume that there aren't SWPs in
the form.

> If it does, then it must be because the caller explicitly arranged for
> it to happen and so the caller could be in charge of binding
> that variable.

The caller could be any lisp function.  It's just that binding
symbols-with-pos-enabled in byte-compile is cheap and harmless, and there
might well be legitimate cases that need it.  I can't think of any at the
moment, though.


> >>     And why bother stripping the result of `byte-compile-eval`?

I think this point is moot if the form has been stripped before going
into byte-compile-eval.  In that case, there will be no need to strip the
result.

[ .... ]

> >>     Fundamentally, `eval` should always strip before doing its job.
> > You mean, by "always", you meant ALWAYS???

> Yes.

> > I understood you to mean "always, when in the context of
> > eval-{when,and}-compile".  If we're not inside a compilation, and thus
> > there're no SWPs hanging around, stripping symbols from an expression
> > will just mean a loss of time for a null operation.

> That's right: the only cases where not stripping the arg of `eval` is OK
> is when we know that stripping would do nothing.
> IOW it's an optimization.

It's NOT an optimisation.  It's a straightforward implementation of the
design.  To add unnecessary stripping of non-existent symbol positions
would be a pessimisation, a possibly measurable slowing down of Emacs.

The whole essence of the SWP design was to minimise the influence of the
SWPs on code which isn't the compiler.  Always stripping before calling
`eval' would not be in accordance with that design.

There are a lot of places where `eval' is called.  Inserting
byte-run-strip-symbol-positions before each of them would be tedious in
the extreme.  Instead damaging `eval', to make it do two disparate things
which just happen to follow on from eachother sometimes, would be worse;
it would likely involve adding an extra &optional argument meaning
"strip".

[ .... ]

> >> The misbehavior I'm referring to is what happens when you call the
> >> function before you byte-compile it (or, more likely, when you never end
> >> up byte-compiling it), because the presence of sympos in the function
> >> will mess up its semantics (because `symbols-with-pos-enabled` won't be
> >> set any more when it's called).

> > I'm puzzled.  Are we still talking about eval-{when,and}-compile, here?

> No.  We're talking about a hypothetical case where `(eval '(defun foo ...))`
> is executed somehow and where the `(defun foo ...)` part somehow
> contains symposes.

Modulo bugs, I think that could only happen in a macro, where the (defun
foo ...) bit was an argument, and the macro takes steps to preserve that
argument beyond its natural scope.

> I used it as an example of why `eval` should conceptually always strip
> its argument (or if `eval` doesn't do it, then its caller should make
> sure that the code passed to it doesn't contains symposes).

I think it will be rare.

[ .... ]

I will prepare another patch which strips the forms of SWPs before the
`eval' in eval-{when,and}-compile.

Apologies if I've inadvertently failed to answer any open points.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2022-03-13 16:49 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-21  0:12 bug#54079: 29.0.50; Method dispatching eratically fails Michael Heerdegen
2022-02-21  1:14 ` Michael Heerdegen
2022-03-04 16:12   ` Lars Ingebrigtsen
2022-02-21  3:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-21  4:21   ` Michael Heerdegen
2022-02-22 23:55     ` Michael Heerdegen
2022-02-23  0:27       ` Michael Heerdegen
2022-02-23  0:47         ` Michael Heerdegen
2022-03-04  2:08           ` Michael Heerdegen
2022-03-04 19:11             ` Alan Mackenzie
2022-03-05 16:37             ` Alan Mackenzie
2022-03-05 17:57               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-03-05 19:00                 ` Alan Mackenzie
2022-03-05 23:01                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-03-05 18:19               ` Eli Zaretskii
2022-03-05 19:07                 ` Alan Mackenzie
2022-03-06  2:19               ` Michael Heerdegen
2022-03-08 19:28                 ` Alan Mackenzie
2022-03-08 19:53                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-03-08 20:48                     ` Alan Mackenzie
2022-03-08 21:03                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-03-09 17:42                         ` Alan Mackenzie
2022-03-09 18:06                           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-03-09 20:32                             ` Alan Mackenzie
2022-03-09 22:04                               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-03-11 22:01                                 ` Alan Mackenzie
2022-03-12  4:23                                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-03-13 16:49                                     ` Alan Mackenzie [this message]
2022-03-14 12:10                                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-03-09  4:10                   ` Michael Heerdegen
2022-03-09 17:29                     ` Alan Mackenzie
2022-03-16  1:44                       ` Michael Heerdegen
2022-03-16 11:52                         ` Alan Mackenzie
2022-03-16 19:22                           ` Michael Heerdegen
2022-03-17  2:58                           ` Michael Heerdegen
2022-03-16 19:29                         ` 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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=Yi4gtl9CfzJsJRfA@ACM \
    --to=acm@muc.de \
    --cc=54079@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=michael_heerdegen@web.de \
    --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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).