[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65516: 30.0.50; Edebug behavior of signaling errors in &or
From: |
Gerd Möllmann |
Subject: |
bug#65516: 30.0.50; Edebug behavior of signaling errors in &or |
Date: |
Mon, 28 Aug 2023 07:52:13 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Stefan Monnier <monnier@iro.umontreal.ca> writes:
> Michael Heerdegen [2023-08-28 00:58:31] wrote:
>> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>>> Hmm... actually, looking at `def-form` again it seems it doesn't use
>>> `&define` nor `(edebug-)gate`.
>> Dunno if this helps, I'm understanding it only half, but AFAIU,
>> `def-form` falls back to `edebug-form' which looks at &define and uses
>> `edebug-gate' indirectly when calling `edebug-list-form'.
>
> Hmm... Could be, indeed. In any case, this "gate" business is
> quite messy.
Yup :-)
>
> I'd be tempted to start removing uses of it, bit by bit, to try and see
> what breaks. And if needed, maybe add a new replacement for it that
> would be better defined (I'm imagining a kind of "scoped gate", which
> could look like `[&gate-in ... [&gate-lock ...SPECS...] ...]` such
> that if `...SPECS...` fails to match, we propagate this failure
> immediately up to the `gate-in`).
>
> This way
>
> [&gate-in [&or ["foo" &gate-lock ...]
> ["foo" "bar"]]]
>
> would never fallback to ["foo" "bar"] whereas
>
> [&or [&gate-in ["foo" &gate-lock ...]]
> ["foo" "bar"]]]
>
> would fallback to ["foo" "bar"] if "..." fails to match.
That's a possibility. I can't say much more because I fail to
understand the motivation why gate is used in the first place. What did
the developers using it want to achieve?