bug#65620: void function edebug-after

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

Alan Mackenzie <acm@muc.de> writes:

> Hello, Gerd.

Hallo Alan, Grüße nach Nürnberg :-).

>
> On Thu, Aug 31, 2023 at 09:55:18 +0200, Gerd Möllmann wrote:
>> Michael Heerdegen <michael_heerdegen@web.de> writes:
>
>> > Alan Mackenzie <acm@muc.de> writes:
>
>> >> (defmacro hash-if (condition then-form &rest else-forms)
>> >>   "A conditional compilation macro analogous to C's #if.
>> >> Evaluate CONDITION at macro-expansion time.  If it is non-nil,
>> >> expand the macro to THEN-FORM.  Otherwise expand it to ELSE-FORMS
>> >> enclosed in a `progn' form.  ELSE-FORMS may be empty."
>> >>   (declare (indent 2)
>> >>            (debug (form sexp &rest sexp)))
>> >>   (if (eval condition lexical-binding)
>> >>       then-form
>> >>     (cons 'progn else-forms)))
>
>> > Dunno if someone is able to fix this (I'm not).  Until then using
>> > `def-form` `or `sexp` instead of `form` works in a better way (the
>> > former edebugs CONDITION when instrumenting, the latter would omit
>> > edebugging the CONDITION entirely).
>
>> > Anyway, the key point in the above example is that macroexpanding (while
>> > instrumenting) combined with the `eval' call seems to lead to the
>> > evaluation of instrumented code outside of an Edebug session when
>> > CONDITION is instrumented using `form`.  `eval-when-compile' uses
>> > `def-form` for example - I guess using `form` in this case doesn't work
>> > as one might expect.
>
>> I think what's happening here is like this:
>
>> By using 'form' for condition, we're telling edebug to instruments it.
>> That is, the argument eval sees when foo is instrumented is whatever
>> edebug wraps around the condition (< ...), and that contains the
>> eval-after.  Using sexp for the condition doesn't instrument the condition.
>
> Or, put a different way, edebug has instrumented CONDITION, then tries to
> evaluate this.  This fails because there is no call to
> edebug-make-enter-wrapper around the thing, which would defalias
> edebug-after and edebug-before, and set up several lists that edebug
> needs.

I think that's correct, but I wouldn't say Edebug evaluates CONDITION,
but we probably mean the same thing: CONDITION is instrumented and
HASH-IF then gets that as argument when FOO is macroexpanded.  Then the
execution of HASH-IF tries to evaluate the instrumented condition etc.

>> One can follow that in the backtrace.
>
>> So, I guess there's nothing to fix here.
>
> I don't think I agree.  eval (and probably apply and funcall and its
> variants) should somehow generate an "optional" edebug-make-enter-wrapper
> around them.  This is currently not done.

That would be one way.  On the other hand, the instrumentation of
CONDITION is actually kind of pointless, because nothing will be
left of it in the fully macroexpanded FOO.  So, one cannot step through
CONDITION with Edebug anyway.