[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#68075: 30.0.50; New special form `handler-bind`
From: |
Eli Zaretskii |
Subject: |
bug#68075: 30.0.50; New special form `handler-bind` |
Date: |
Sun, 31 Dec 2023 21:36:05 +0200 |
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: 68075@debbugs.gnu.org
> Date: Sun, 31 Dec 2023 14:07:18 -0500
>
> >> >> +@var{handler} is called in the dynamic context where the error
> >> >> +happened, without first unwinding the stack, meaning that all the
> >> >> +dynamic bindings are still in effect,
> >> >
> >> > Should we tell something about the effects of lexical-binding on those
> >> > "dynamic bindings"?
> >>
> >> It's not related to `handler-bind` in any case, so if
> >> we want to say something about it, we should do it elsewhere (and
> >> I think we already do when we discuss lexical binding).
> >
> > Maybe I'm confused by your use of "dynamic context" and "dynamic
> > bindings" in that passage, which somehow hinted on dynamic vs lexical
> > binding.
>
> Of course: "dynamic context" refers to things that include dynamically
> bound variable (as well as the set of active catch tags, error handlers,
> and unwind-protect forms), and does not include statically bound
> variables. `handler-bind` is different from `condition-case` in the way
> it interacts with that dynamic context. But for statically bound
> variables, well, they obey the rules of static scoping so there's
> nothing to influence here.
>
> > If this is irrelevant, maybe try to reword the text so that
> > this potentially confusing terminology is not used?
>
> Could you give an example piece of code where this "confusing
> terminology" makes you unsure how things would work?
That's the quoted part of your patch at the beginning of this message.
It uses the word "dynamic" twice and "dynamic bindings" once.