Probably normal but how to get it to work?

[dunbarx]

Jacque.

Right, though I don't get it. I thought, and I bet Simon will concur, that this is what should happen:

Code: Select all

local x = 0
on mouseUp
   add 1 to x
   if x < 4 then doStuff
   breakpoint
   beep 
end mouseUp

on dostuff
end dostuff

One beep. So my issue is this: why do recursive calls nest at all? It feels like some extra and spurious process is going on, sneaking into the mix without being asked. Interlopers. Obviously. I am wrong.

Craig

[WaltBrown]

If you put "mouseUp" within "doStuff", you have identical performance.

Here's a stack with both methods, modified so you can see and hear the process, along with a picture of the path of execution. It acts exactly as I would expect it to act.

I may still not understand the original issue.

Walt

wbRecursion.zip

(15.22 KiB) Downloaded 282 times

[jacque]

Good diagram, that's exactly what I was trying to describe. It's hard to wrap your brain around recursion, this is a nice explanation.

[dunbarx]

Walt

It sounds like you do understand. I do as well, I just don't get it. The inclusion of "mouseup" in the "doStuff" handler is identical to leaving it in the original. As you know.

I am trying to grok why the "balance", or rather, the totality of the mouseUp handler is made inclusive. Each recursive call exits at the same point, above the "beep". And that is my point. I understand why they nest, I just don't get why the whole handler is "queued", and not just the section before the "exit" point. In other words, I feel that only the original balance of the original handler should execute once all calls are made and run their course.

Will sleep on it again...

Craig

[jacque]

Craig,

They don't exit, just as calling "doStuff" wouldn't exit the mouseUp handler that called it. When a handler calls another one, the remainder of the original is suspended until the called handler finishes; then it continues where it left off. (I know you already know that.) There is no difference between calling "doStuff" and then returning to the last 2 lines of mouseUp, and calling "mouseUp" inside of itself. The first mouseUp will suspend the remaining lines until the second one finishes, at which point it picks up where it left off. The more times a handler calls itself, the more suspensions queue up. They unwind as each nested call completes.

[[-hh]]

..........

[dunbarx]

Hermann, Jacque, et al.

And now: Isn't it correct that a recursive call should exactly work like this, start again (with possibly new parameters) but don't exit?

Of course. What on earth was the problem?

Craig

[[-hh]]

..........

[jacque]

LOL. A mutual friend of Craig and me called it a "thinko". I adopted the term.

[dunbarx]

Hermann.

I am a hobbyist, not a grandMaster. Jacque is a grandMaster. Unless ordinary decrepitude counts for something, I rely on a sense of humor, not wizardry.

Craig

[sritcp]

Would this work?

beep
exit to top

The dictionary says
if the current handler was called from another handler, the calling handler is also halted.

Regards,
Sri.

[dunbarx]

Surely.

The problem was mental, not programmatic. It wasn't that one could not exit explicitly, but that the "natural" construction of nested handler calls would not include the portion of interior handlers BELOW each call. Seems utterly simple now...

Craig