bug#65620: void function edebug-after

[Alan Mackenzie <acm@muc.de>]

Hallo, Gerd,

Grüß aus Nürnberg!

On Thu, Aug 31, 2023 at 16:41:21 +0200, Gerd Möllmann wrote:
> Alan Mackenzie <acm@muc.de> writes:

> 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.

I think I've got it, now.  Considering that hash-if evaluates CONDITION,
it is an error for edebug to evaluate CONDITION as an argument first;
there would be a sort of "double evaluation".  So I need to use sexp
rather than form in the edebug spec, like Michael and you have been
telling me all along.  :-)

> >> 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.

Yes.  This is a shame, since it would be nice to step through CONDITION,
particularly if it is complicated.

I think a better way of handling this would be to have a "base function"
for edebug-after (and for edebug-before), as opposed to the nil that each
of these currently has.  These functions would throw an error asking the
user to check the edebug spec.  Something like (untested):

    (defun edebug-after (before-index after-index form)
      "Version of `edebug-after' to call when edebug is not yet set up.
    This function gets temporarily replaced by a real function when
    edebug becomes active."
      (error "Invalid call to `edebug-after' for %S: Is your debug spec \
    correct?" form))

..  What do you think?

-- 
Alan Mackenzie (Nuremberg, Germany).