Nested Gosubs

[John Esak]

> Actually, I hope you are not advocating this kind of programming as shown
> above.. other than to illustrate _very_bad_programming_.  This is
> _precisely_ the kind of spaghetti code that we are all always fixing for
> people who are just starting out... or who have made and error in their
> coding and can't debug it becaus of things like this.  You should never
> allow a SCREEN command to come up in @when processing if you
> don't *WANT* it
> to specifically end that when-processing snippet.  There is no
> justification
> for this, since there are umpteen-dozen other ways of writing this to work
> exactly as the "intent" of this code is meant to work.  Especially, since
> this code is so "mixed_up" (which I'm sure you meant it to be) as to imply
> that the goto calc would always execute...which, obviously, you
> are pointing
> out, it won't.  Coming from the when-processing you show, the "goto calc"
> will not get executed... so it doesn't really show any kind of
> example... of
> anything good at all.  If CALC were only called as a subroutine from INPUT
> procesing, yes it would function, but the point is, don't do it from a
> when-leaving situation.  So, therefore, in my opinion, it is a very badly
> constructed subroutine... and shouldn't be used ever anyway.
>
> John

The following code will give Too Many Nested GOSUB's
after 64 iterations...  It also shows where code will not be executed... if
one were ever to write such bad code.  The point is, that breaking out of a
GOSUB routine from within any @wlf/ef processing is a _very_ bad idea. Even
it it seems to work because other factors allow it to do so... eventually,
you are going to hit the error.

::end:
@wlf1:::
::i(3,.0)=i+"1":
:i gt "60":show "@now at" < i:
::gosub there:
::show "@You'll never see this.":
::end    'this END will never be executed:
there::screen 2,3:
::return  'this RETURN will never be executed: