Nested Gosubs

[John Esak]

> -----Original Message-----
> Gotcha.   Thanks for the detailed example.  I wasn't actually
> aware of that
> constraint, so I'm glad you clarified it.

The constraint is only relevant to @wlf and @wef processing.


> I don't suppose someone would consider wishlisting an addition where GOSUB
> actually backs off when it encounters any statement tantamount to END?
> I've known for 11 years that SCREEN acts as a de-facto END (although I
> thought there was a situation in which you needed and END after SCREEN
> anyway, back in the day.  It seems like the GOSUB system should respect
> that somehow.




>
> Actually, without thinking for an hour on all implications and just musing
> off the cuff, shouldn't an END (or equivalent statement) not just back off
> one nesting, but effectively nuke -all- active GOSUB's on the stack, since
> processing ends at that point--there's no need to track them further than
> the end of the road, is there?  Seems like the logic equivalent
> of a memory
> leak, here.
>
> Just a thought.
>

It absolutely does... The SCREEN is _not_ a de-facto 'end' of any kind for
regular INPUT processing (the processing pointer which starts at the top of
the table... will simply -stop- at a SCREEN and wait there while the user is
busy throwing junk on the screen. When the user presses the SAVE key, the
processing pointer takes up from that point and moves on until it hits
another function which may give control to the user... or it hits and END or
and EXIT or whatever.

The difference is that for any @wlf or @wef, a SCREEN command (and a END,
SKIP, or RESTART) actually _do_ stop the processing pointer right there
forever. They stop the @when_field processing pointer, NOT the main INPUT
table pointer.

So, GOSUB's and RETURNS do act as they should (and they do just un-nest one
GOSUB back) until the original GOSUB is hit.

John

Thanks for the nice words about my writings about filePro... it is great to
hear that they are clear sometimes...   When I'm talking to Ken, I often
feel like I know nothing about the program, though. :-)