[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#65620: void function edebug-after
From: |
Alan Mackenzie |
Subject: |
bug#65620: void function edebug-after |
Date: |
Fri, 1 Sep 2023 09:23:35 +0000 |
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).