bug#65516: 30.0.50; Edebug behavior of signaling errors in &or

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

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?