[no subject]

[DCH@MIT-ML]

Inside DIDL, an LSUBR, I do  (EVALHOOK form 'DIDL-EVALHOOK-STEP)


EVALHOOK does the right thing, and calls DIDL-EVALHOOK-STEP, a SUBR,
with (* 2 3).  Then DIDL-EVALHOOK-STEP does (DIDL form).

Now DIDL does EVALFRAME's.  The first frame it gets is a frame for
(+ (* 2 3) 4).  It does not find a frame for DIDL-EVALHOOK-STEP on top
of the stack.  This I sort of expect, because the call to DIDL was through
a snapped UUO.

However, if I now do a ^B, and do EVALFRAME's by hand, the first frame I
get is (... (DIDL-EVALHOOK-STEP ((* 2 3)) ...), with the (+ (* 2 3) 4)
frame underneath it.

So why does the DIDL-EVALHOOK-STEP frame suddenly appear?  For the DIDL
debugger, I actually want it, and it seems I'd have to compile in (nouuo t)
mode to get it.  But if ^B can "create" the frame, can I too?

If that isn't possible, here's a suggestion:
I don't want to compile everything in (nouuo t) mode because I think it
would probably slow the running of the compiled code down noticeably.
However, I do want to have frames created for a few routines like DIDL
and DIDL-EVALHOOK-STEP.  So it would be nice if I could say
(nouuo (DIDL DIDL-EVALHOOK-STEP)) to turn on nouuo only for these routines.

I don't know how (nouuo t) works now, but I guess that it sets a global flag
so that the uuo handler doesn't replace the uuo.  So it would be inefficient
to have the uuo handler search a list everytime to see what links should and
shouldn't be snapped.  But, if instead, there were TWO uuo's, one meaning
"snap me", and the other meaning "don't snap me", then the compiler could
generate the appropriate uuo, and the uuo handler wouldn't have to worry about
anything.
--Dan