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

[Gerd Möllmann]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

(Adding Michael in CC because he might be interested.)

>> My question is about edebug-no-match.  Do you perhaps have an idea what
>> the reason might be why it ever chooses to signal an error instead of
>> just throwing no-match?
>
> `edebug-no-match` is the only place where we test `edebug-gate`, so if
> we make it throw to `no-match` it would make `gate` into a no-op.

Yes.

> (`gate` doesn't occur explicitly in your example, but it's implicitly
> present inside other things like `&define`, and hence `def-form`,
> IIRC).

Correct.

> In a sense `gate` is supposed to be a bit like Prolog's "cut", but
> Edebug isn't quite like Prolog (e.g. it doesn't really do backtracking;
> it works more like a PEG parser) and similarly its `gate` isn't the same
> as "cut".

Right.  

> See bug#41988 for a case where we didn't want a failure in one
> "definition form" to be allowed to continue matching in a second branch
> of an `&or` (tho this was arguably because some of the code executed
> along the way had side-effects that can't be undone).

Hurrah! :-)  Yes, that's it!  Thank you so much, that made my day!


As a fix, I'd like to propose to remove 'gate' as a debug spec entirely.

Reasons are:

- I doubt it's very useful to signal invalid-read-error while matching.
In fact, I found it very confusing, when I got it, wondering how the
Lisp reader comes into play here.  And the signal didn't give me any
helpful info either.

- I can't imagine anyone using 'gate' as it is.  I just don't see a
use-case for it.

I know that could be considered radical.  But, so what?

WDYT?