bug#41988: 28.0.50; Edebug unconditionally instruments definitions with &define specs

[Philipp Stephani]

Am So., 4. Apr. 2021 um 22:16 Uhr schrieb Stefan Monnier
<monnier@iro.umontreal.ca>:
>
> >> [ Disclaimer: I don't understand the precise semantics of `gate`, tho
> >>   I do remember using it once via trial-and-error.  So maybe it wouldn't
> >>   prevent it, but if doesn't prevent it, then it doesn't likely "fix"
> >>   our problem ;-)  ]
> > AIUI the semantics of "gate" aren't that complex, it just means "don't
> > backtrack beyond this point."
>
> [ Yes, that's the part I understand.  But it's not clear where
>   backtracking is possible and where it's not.  At least, the code that
>   I saw in edebug.el didn't match my expectations back when I looked at
>   it, hence my not feeling quite sure what the semantics are (and/or
>   should be).
>   IIRC the issue was that the scope of that effect wasn't clear: if you
>   think of Prolog's cut, its effect is local to a particular definition,
>   whereas I think the scope of `gate` is not nearly as clear because
>   there isn't such a notion of "definition".  ]

I agree that the code isn't terribly clear and probably has some bugs.
However, the "prevent backtracking through gates" seems to work at
least somewhat (experimentally, in this case I can turn the double
definition into an error).

> >> > so I think it would be reasonable to prevent.  We already
> >> > disable backtracking for literal symbols, and I think forms that require
> >> > multiple &define forms with backtracking should be exceedingly rare and 
> >> > can
> >> > be rewritten as you did with cl-flet.
> >> Emitting a warning would be much more helpful than just silently
> >> "cut"ting the backtracking.
> > A gate isn't silent, it would cause a hard error in this case.
>
> What I meant is that a gate would just make the old cl-flet spec fail in
> most cases, with no explanation why that spec now fails even though it
> worked in the past.

Yes, we'd need to at least announce the change in NEWS as an
incompatible Lisp change. However, I think overall that's still better
than the current situation: with your fix to cl-flet the problematic
constructs shouldn't occur any more in the Emacs codebase, and I
wouldn't expect such constructs to be very frequent "in the wild", so
the overall breakage would be very small, and if it can avoid
similarly subtle bugs then I think it's warranted.