Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #24668 > unrolled thread

How to abort loops and other return stack fiddling words…

Back to article view | Back to comp.lang.forth

Contents

  How to abort loops and other return stack fiddling words… Christian Kellermann <ckeen@pestilenz.org> - 2013-07-22 11:54 +0200
    Re: How to abort loops and other return stack fiddling words… Mark Wills <markrobertwills@yahoo.co.uk> - 2013-07-22 04:18 -0700
      Re: How to abort loops and other return stack fiddling words… Christian Kellermann <ckeen@pestilenz.org> - 2013-07-22 14:31 +0200
        Re: How to abort loops and other return stack fiddling words… daveyrotten <danw8804@gmail.com> - 2013-07-22 08:31 -0700
      Re: How to abort loops and other return stack fiddling words… Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-07-22 13:56 +0100
        Re: How to abort loops and other return stack fiddling words… Mark Wills <markrobertwills@yahoo.co.uk> - 2013-07-22 06:46 -0700
          Re: Re: How to abort loops and other return stack fiddling words… anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-07-22 16:01 +0000
            Re: How to abort loops and other return stack fiddling words… rickman <gnuarm@gmail.com> - 2013-07-22 12:31 -0400
              Re: Re: How to abort loops and other return stack fiddling words… anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-07-22 16:36 +0000
              Re: How to abort loops and other return stack fiddling words… "Ed" <invalid@invalid.com> - 2013-07-24 12:18 +1000
              Re: How to abort loops and other return stack fiddling words? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-24 02:48 -0500
                Re: How to abort loops and other return stack fiddling words? rickman <gnuarm@gmail.com> - 2013-07-27 22:15 -0400
                  Re: How to abort loops and other return stack fiddling words? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-28 03:37 -0500
                    Re: How to abort loops and other return stack fiddling words? rickman <gnuarm@gmail.com> - 2013-07-29 11:01 -0400
                      Re: How to abort loops and other return stack fiddling words? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-29 11:07 -0500
                        Re: How to abort loops and other return stack fiddling words? rickman <gnuarm@gmail.com> - 2013-07-29 12:32 -0400
                          Re: How to abort loops and other return stack fiddling words? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-29 11:54 -0500
                            Re: How to abort loops and other return stack fiddling words? rickman <gnuarm@gmail.com> - 2013-07-29 13:19 -0400
                              Re: How to abort loops and other return stack fiddling words? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-29 15:27 -0500
                  Re: How to abort loops and other return stack fiddling words? Mark Wills <markrobertwills@yahoo.co.uk> - 2013-07-28 03:20 -0700
                    Re: How to abort loops and other return stack fiddling words? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-28 08:17 -0500
          Re: How to abort loops and other return stack fiddling words… Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-07-22 18:07 +0100
        Re: Re: How to abort loops and other return stack fiddling words… albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-07-22 14:12 +0000
          Re: How to abort loops and other return stack fiddling words… Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2013-07-22 17:49 +0100
        Re: How to abort loops and other return stack fiddling words… hughaguilar96@yahoo.com - 2013-07-22 20:25 -0700
    Re: How to abort loops and other return stack fiddling words? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-07-22 07:54 -0500

Page 1 of 2  [1] 2  Next page →

#24668 — How to abort loops and other return stack fiddling words…

Hi,

I have a couple of words in my robots program that involve looping and
jumping out of said loops. The latter has been hard for me to get right
and I could not find examples or descriptions on how to do this. So
questions are:

How can I end:

a ) BEGIN ... AGAIN
b ) DO... LOOP
c ) CASE ... ENDCASE

Thanks for your help!

Christian

[toc] | [next] | [standalone]

#24672

a) you can't. At least, not without carnal knowledge of your system. It's an infinate loop, by design, so if you find you need to jump out of it, it means you shouldn't be using it ;-)

Example code using AGAIN: http://turboforth.net/lang_ref/view_word.asp?ID=71

b) See this example for do/loop with LEAVE: http://turboforth.net/lang_ref/view_word.asp?ID=83

c) n case
  a of code-for-case-a endof
  b of code-for-case-b endof
  c of code-for-case-c endof
  code-for-no-matching-case
endcase

Example code using CASE: http://turboforth.net/lang_ref/view_word.asp?ID=74

Obviously, if case a b or c *is* detected, then the default (i.e. no match) code is *not* executed.

Have a look at BEGIN...UNTIL. That might be better for your needs. Here's an example:

http://turboforth.net/lang_ref/view_word.asp?ID=72

HTH

[toc] | [prev] | [next] | [standalone]

#24675

Mark Wills <markrobertwills@yahoo.co.uk> writes:

> a) you can't. At least, not without carnal knowledge of your
> system. It's an infinate loop, by design, so if you find you need to
> jump out of it, it means you shouldn't be using it ;-)

Ah, ok. Makes sense.

> Example code using AGAIN: http://turboforth.net/lang_ref/view_word.asp?ID=71
>
> b) See this example for do/loop with LEAVE:
> http://turboforth.net/lang_ref/view_word.asp?ID=83

> c) n case
>   a of code-for-case-a endof
>   b of code-for-case-b endof
>   c of code-for-case-c endof
>   code-for-no-matching-case
> endcase

The reason why I ask this is: For the robot game I have a dispatch case
reacting to user input. Now if I want to add an option to restart a
game, I could just call the restart-game word again but as I understand
it, this would grow the stack. Maybe I should restructure the code in
this case to a control flow better suited for these new specifications
instead.

>
> Obviously, if case a b or c *is* detected, then the default (i.e. no
> match) code is *not* executed.  Have a look at BEGIN...UNTIL. That
> might be better for your needs. Here's an example:

BEGIN...UNTIL look like a candidate for said restructuring.

Thank you!

Christian

[toc] | [prev] | [next] | [standalone]

#24683

On Monday, July 22, 2013 7:31:48 AM UTC-5, Christian Kellermann wrote:
> 
> > c) n case
> >   a of code-for-case-a endof
> >   b of code-for-case-b endof
> >   c of code-for-case-c endof
> >   code-for-no-matching-case
> > endcase
> 
> The reason why I ask this is: For the robot game I have a dispatch case
> reacting to user input. Now if I want to add an option to restart a
> game, I could just call the restart-game word again but as I understand
> it, this would grow the stack. Maybe I should restructure the code in
> this case to a control flow better suited for these new specifications
> instead.
> 
> 
> 
For user input you might want to consider an alternative to the CASE statement. Turns out you can compile words which anticipate each command available to the user. Then you write a handler that builds each word as the user is entering the command and then vectors execution to that word. That way you make the existing dictionary code do most of the work for you. It blew me away the first time I saw this done in Samuel A. Falvo II's code for his VIBE program. It's efficient and the resulting code ends up better factored and more compact (IMHO).


http://tunes.org/wiki/block_20editor.html

See especially the sections on "Editor Commands" and "Editor Keyboard Handler".

[toc] | [prev] | [next] | [standalone]

#24677

On 22/07/2013 12:18, Mark Wills wrote:
> a) you can't. At least, not without carnal knowledge of your system. It's an infinate loop, by design, so if you find you need to jump out of it, it means you shouldn't be using it ;-)
>

Of course you can exit a BEGIN ... AGAIN loop. Possibilities are:

1. THROW an exception to an external CATCH

2. Put the loop inside its own colon definition and use EXIT e.g
    : foo ... begin ... if exit then ... again ;

3. Manipulate the control-flow stack e.g.

    : exit-loop  postpone ahead 1 cs-roll ; immediate
    : foo
       begin
          cr ." Entered loop"
          exit-loop
       again then
       cr ." Exited loop"
    ;


-- 
Gerry

[toc] | [prev] | [next] | [standalone]

#24678

All of which voids the entire point - that an AGAIN loop is *supposed* to be infinate. So if you *do* need to exit the loop, you shouldn't be using it.

[toc] | [prev] | [next] | [standalone]

#24690

Mark Wills <markrobertwills@yahoo.co.uk> writes:
>All of which voids the entire point - that an AGAIN loop is *supposed* to be infinate. So if you *do* need to exit the loop, you shouldn't be using it.

Maybe that's your house style, but not everybody has to follow your
house style.  In standard Forth AGAIN is just an unconditional branch
backwards.  You can use it for building infinite loops, but also for
other purposes.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#24691

On 7/22/2013 12:01 PM, Anton Ertl wrote:
> Mark Wills<markrobertwills@yahoo.co.uk>  writes:
>> All of which voids the entire point - that an AGAIN loop is *supposed* to be infinate. So if you *do* need to exit the loop, you shouldn't be using it.
>
> Maybe that's your house style, but not everybody has to follow your
> house style.  In standard Forth AGAIN is just an unconditional branch
> backwards.  You can use it for building infinite loops, but also for
> other purposes.

Do you have examples of loops with exits that are better served by AGAIN 
than they are with UNITL or WHILE?  Are you talking about error 
handling?   I can't think of any example where I thought it better to 
make an infinite loop with an error exit than just using a loop with an 
exit condition like UNTIL or WHILE.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#24692

rickman <gnuarm@gmail.com> writes:
>On 7/22/2013 12:01 PM, Anton Ertl wrote:
>> Mark Wills<markrobertwills@yahoo.co.uk>  writes:
>> Maybe that's your house style, but not everybody has to follow your
>> house style.  In standard Forth AGAIN is just an unconditional branch
>> backwards.  You can use it for building infinite loops, but also for
>> other purposes.
>
>Do you have examples of loops with exits that are better served by AGAIN 
>than they are with UNITL or WHILE?

First of all, AGAIN is a factor or REPEAT:

: repeat postpone again  postpone then ; immediate

I also think that, when you have multiple WHILEs, it's better to use
AGAIN instead of REPEAT.  Then you just use n THENs for n WHILEs, not
n-1 THENs.  E.g.:

BEGIN
  ... WHILE
    ... WHILE
      ... WHILE
        ...
AGAIN THEN THEN THEN

instead of 

BEGIN
  ... WHILE
    ... WHILE
      ... WHILE
        ...
REPEAT THEN THEN

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2013: http://www.euroforth.org/ef13/

[toc] | [prev] | [next] | [standalone]

#24750 — Re: How to abort loops and other return stack fiddling words…

rickman wrote:
> ...
> I can't think of any example where I thought it better to
> make an infinite loop with an error exit than just using a loop with an
> exit condition like UNTIL or WHILE.

Yes.  It's for that reason AGAIN is optional in ANS.

[toc] | [prev] | [next] | [standalone]

#24754 — Re: How to abort loops and other return stack fiddling words?

rickman <gnuarm@gmail.com> wrote:
> On 7/22/2013 12:01 PM, Anton Ertl wrote:
>> Mark Wills<markrobertwills@yahoo.co.uk>  writes:
>>> All of which voids the entire point - that an AGAIN loop is
>>> *supposed* to be infinate. So if you *do* need to exit the loop,
>>> you shouldn't be using it.
>>
>> Maybe that's your house style, but not everybody has to follow your
>> house style.  In standard Forth AGAIN is just an unconditional branch
>> backwards.  You can use it for building infinite loops, but also for
>> other purposes.
> 
> Do you have examples of loops with exits that are better served by AGAIN 
> than they are with UNITL or WHILE?  Are you talking about error 
> handling?   I can't think of any example where I thought it better to 
> make an infinite loop with an error exit than just using a loop with an 
> exit condition like UNTIL or WHILE.

The classic case is

begin
  something
  something_else if  maybe if  yes_action  exit  then  step  then
  more
again

It's possible to restructure this, but not easy.

Andrew.

[toc] | [prev] | [next] | [standalone]

#24822 — Re: How to abort loops and other return stack fiddling words?

On 7/24/2013 3:48 AM, Andrew Haley wrote:
> rickman<gnuarm@gmail.com>  wrote:
>> On 7/22/2013 12:01 PM, Anton Ertl wrote:
>>> Mark Wills<markrobertwills@yahoo.co.uk>   writes:
>>>> All of which voids the entire point - that an AGAIN loop is
>>>> *supposed* to be infinate. So if you *do* need to exit the loop,
>>>> you shouldn't be using it.
>>>
>>> Maybe that's your house style, but not everybody has to follow your
>>> house style.  In standard Forth AGAIN is just an unconditional branch
>>> backwards.  You can use it for building infinite loops, but also for
>>> other purposes.
>>
>> Do you have examples of loops with exits that are better served by AGAIN
>> than they are with UNITL or WHILE?  Are you talking about error
>> handling?   I can't think of any example where I thought it better to
>> make an infinite loop with an error exit than just using a loop with an
>> exit condition like UNTIL or WHILE.
>
> The classic case is
>
> begin
>    something
>    something_else if  maybe if  yes_action  exit  then  step  then
>    more
> again
>
> It's possible to restructure this, but not easy.

Wow! I can't even understand what this is saying.  What are "maybe" and 
"step"?  I guess I don't get any sense of why this code is written this 
way.

begin
    something
    something_else maybe OVER AND 0= while if  step  then
    more
repeat
yes_action  ;

Is that so complex?  Did I miss something?  Have you ever needed to use 
something like this?

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#24826 — Re: How to abort loops and other return stack fiddling words?

rickman <gnuarm@gmail.com> wrote:
> On 7/24/2013 3:48 AM, Andrew Haley wrote:
>> rickman<gnuarm@gmail.com>  wrote:
>>> On 7/22/2013 12:01 PM, Anton Ertl wrote:
>>>> Mark Wills<markrobertwills@yahoo.co.uk>   writes:
>>>>> All of which voids the entire point - that an AGAIN loop is
>>>>> *supposed* to be infinate. So if you *do* need to exit the loop,
>>>>> you shouldn't be using it.
>>>>
>>>> Maybe that's your house style, but not everybody has to follow your
>>>> house style.  In standard Forth AGAIN is just an unconditional branch
>>>> backwards.  You can use it for building infinite loops, but also for
>>>> other purposes.
>>>
>>> Do you have examples of loops with exits that are better served by AGAIN
>>> than they are with UNITL or WHILE?  Are you talking about error
>>> handling?   I can't think of any example where I thought it better to
>>> make an infinite loop with an error exit than just using a loop with an
>>> exit condition like UNTIL or WHILE.
>>
>> The classic case is
>>
>> begin
>>    something
>>    something_else if  maybe if  yes_action  exit  then  step  then
>>    more
>> again
>>
>> It's possible to restructure this, but not easy.
> 
> Wow! I can't even understand what this is saying.  What are "maybe" and 
> "step"?  I guess I don't get any sense of why this code is written this 
> way.

It might be stepping through some kind of data structure, with actions
to be performed iff [1] a node exists and it has a particular value.

> begin
>    something
>    something_else maybe OVER AND 0= while if  step  then
>    more
> repeat
> yes_action  ;
> 
> Is that so complex?  Did I miss something?

Yes, you did.  Perhaps it's not safe to execute MAYBE unless
SOMETHING_ELSE is true.  And it's also a waste of CPU time: as soon as
you've determined that SOMETHING_ELSE is false, there's no point
executing MAYBE .  You can do it with multiple WHILEs, but it's no
easier to understand the code.

> Have you ever needed to use something like this?

Heavens, yes!  Hundreds of times.  There's nothing special about it.
It's not obscure.

Andrew.

[1] http://en.wikipedia.org/wiki/If_and_only_if

[toc] | [prev] | [next] | [standalone]

#24849 — Re: How to abort loops and other return stack fiddling words?

On 7/28/2013 4:37 AM, Andrew Haley wrote:
> rickman<gnuarm@gmail.com>  wrote:
>> On 7/24/2013 3:48 AM, Andrew Haley wrote:
>>> rickman<gnuarm@gmail.com>   wrote:
>>>> On 7/22/2013 12:01 PM, Anton Ertl wrote:
>>>>> Mark Wills<markrobertwills@yahoo.co.uk>    writes:
>>>>>> All of which voids the entire point - that an AGAIN loop is
>>>>>> *supposed* to be infinate. So if you *do* need to exit the loop,
>>>>>> you shouldn't be using it.
>>>>>
>>>>> Maybe that's your house style, but not everybody has to follow your
>>>>> house style.  In standard Forth AGAIN is just an unconditional branch
>>>>> backwards.  You can use it for building infinite loops, but also for
>>>>> other purposes.
>>>>
>>>> Do you have examples of loops with exits that are better served by AGAIN
>>>> than they are with UNITL or WHILE?  Are you talking about error
>>>> handling?   I can't think of any example where I thought it better to
>>>> make an infinite loop with an error exit than just using a loop with an
>>>> exit condition like UNTIL or WHILE.
>>>
>>> The classic case is
>>>
>>> begin
>>>     something
>>>     something_else if  maybe if  yes_action  exit  then  step  then
>>>     more
>>> again
>>>
>>> It's possible to restructure this, but not easy.
>>
>> Wow! I can't even understand what this is saying.  What are "maybe" and
>> "step"?  I guess I don't get any sense of why this code is written this
>> way.
>
> It might be stepping through some kind of data structure, with actions
> to be performed iff [1] a node exists and it has a particular value.

Which word does which in the sequence above?  I need this to be a bit 
more concrete.  Your loop runs without executing the 'step' word if 
something_else does not return a TRUE.  So sometimes the loop is 
stepping, other times it isn't... I find that very confusing without 
some idea of context.  Still, it's not really a problem.


>> begin
>>     something
>>     something_else maybe OVER AND 0= while if  step  then
>>     more
>> repeat
>> yes_action  ;
>>
>> Is that so complex?  Did I miss something?
>
> Yes, you did.  Perhaps it's not safe to execute MAYBE unless
> SOMETHING_ELSE is true.  And it's also a waste of CPU time: as soon as
> you've determined that SOMETHING_ELSE is false, there's no point
> executing MAYBE .  You can do it with multiple WHILEs, but it's no
> easier to understand the code.

Ok, but that the intention is hard to tell from the code segment.  I 
think this would be better solved by factoring.

: loop_control
   something_else if maybe if FALSE else TRUE step then then
;

begin
     something
     loop_control while
     more
repeat
yes_action  ;

I don't think this is overly complex and does what you needed, no?

I think my real issue with your example is just the use of EXIT. 
Regardless of how some people practice coding, I learned structured 
programming in college and it made a significant impact on me.  When I 
look at your code example, all sorts of flags pop up in my mind having 
to do with exiting a subroutine from other than the end.  It *does* make 
it harder to read the code (assuming there is any significant code to 
read) and leads to errors which can be harder to debug.

I will grant you that in Forth the short code segments often used make 
the use of EXIT easier and less trouble prone, but as you can see above 
the factoring actually has improved the code so that the main word deals 
with what is being done by the loop while the factored word deals with 
how the loop is controlled.  Also, the yes_action word is outside of the 
loop where (in my mind) it logically belongs (again the structured 
programming influence) not to mention the fact that the factored version 
is just plain easier to read.


>> Have you ever needed to use something like this?
>
> Heavens, yes!  Hundreds of times.  There's nothing special about it.
> It's not obscure.

You are entitled to your coding style.  But I think your premise that 
"It's possible to restructure this, but not easy." is busted.  The only 
hard part was understanding what the example was supposed to do.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#24850 — Re: How to abort loops and other return stack fiddling words?

rickman <gnuarm@gmail.com> wrote:
> On 7/28/2013 4:37 AM, Andrew Haley wrote:
>> rickman<gnuarm@gmail.com>  wrote:
>>> On 7/24/2013 3:48 AM, Andrew Haley wrote:
>>>> rickman<gnuarm@gmail.com>   wrote:
>>>>> On 7/22/2013 12:01 PM, Anton Ertl wrote:
>>>>>> Mark Wills<markrobertwills@yahoo.co.uk>    writes:
>>>>>>> All of which voids the entire point - that an AGAIN loop is
>>>>>>> *supposed* to be infinate. So if you *do* need to exit the loop,
>>>>>>> you shouldn't be using it.
>>>>>>
>>>>>> Maybe that's your house style, but not everybody has to follow your
>>>>>> house style.  In standard Forth AGAIN is just an unconditional branch
>>>>>> backwards.  You can use it for building infinite loops, but also for
>>>>>> other purposes.
>>>>>
>>>>> Do you have examples of loops with exits that are better served by AGAIN
>>>>> than they are with UNITL or WHILE?  Are you talking about error
>>>>> handling?   I can't think of any example where I thought it better to
>>>>> make an infinite loop with an error exit than just using a loop with an
>>>>> exit condition like UNTIL or WHILE.
>>>>
>>>> The classic case is
>>>>
>>>> begin
>>>>     something
>>>>     something_else if  maybe if  yes_action  exit  then  step  then
>>>>     more
>>>> again
>>>>
>>>> It's possible to restructure this, but not easy.
>>>
>>> Wow! I can't even understand what this is saying.  What are "maybe" and
>>> "step"?  I guess I don't get any sense of why this code is written this
>>> way.
>>
>> It might be stepping through some kind of data structure, with actions
>> to be performed iff [1] a node exists and it has a particular value.
> 
> Which word does which in the sequence above?  I need this to be a bit 
> more concrete.  Your loop runs without executing the 'step' word if 
> something_else does not return a TRUE.  So sometimes the loop is 
> stepping, other times it isn't... I find that very confusing without 
> some idea of context.  Still, it's not really a problem.
> 
>>> begin
>>>     something
>>>     something_else maybe OVER AND 0= while if  step  then
>>>     more
>>> repeat
>>> yes_action  ;
>>>
>>> Is that so complex?  Did I miss something?
>>
>> Yes, you did.  Perhaps it's not safe to execute MAYBE unless
>> SOMETHING_ELSE is true.  And it's also a waste of CPU time: as soon as
>> you've determined that SOMETHING_ELSE is false, there's no point
>> executing MAYBE .  You can do it with multiple WHILEs, but it's no
>> easier to understand the code.
> 
> Ok, but that the intention is hard to tell from the code segment.  I 
> think this would be better solved by factoring.
> 
> : loop_control
>   something_else if maybe if FALSE else TRUE step then then
> ;

That works.  It's ugly and wasteful, though.  A fairly common design
principle is not to test the same twice.  So, once you know something,
you act on it.  In this case the action is to quit the loop
immediately.  The

   if FALSE else TRUE ...

is a clue that something bad is going on.  You've got unnecessary
control structures, and with a bit of refactoring you could make them
go away.

> begin
>     something
>     loop_control while
>     more
> repeat
> yes_action  ;
> 
> I don't think this is overly complex and does what you needed, no?

It does, but it is more complex, and it does unnecessary work.

Every program can be restructored into a single WHILE loop, a ton of
flags, and a lot of IF statements.  So, it is possible to say that you
don't ever need to EXIT from an infinite loop.  But sometimes it
really is easier to do so.  And the program I provided is the simplest
classic case.

> I think my real issue with your example is just the use of EXIT.
> Regardless of how some people practice coding, I learned structured
> programming in college and it made a significant impact on me.  When
> I look at your code example, all sorts of flags pop up in my mind
> having to do with exiting a subroutine from other than the end.  It
> *does* make it harder to read the code (assuming there is any
> significant code to read) and leads to errors which can be harder to
> debug.

Structured programming is just helpful advice; it's not holy writ.
The goal is to reduce complexity.  If structured programming helps
with that, fine.  It usually does.

> I will grant you that in Forth the short code segments often used
> make the use of EXIT easier and less trouble prone, but as you can
> see above the factoring actually has improved the code so that the
> main word deals with what is being done by the loop while the
> factored word deals with how the loop is controlled.

Shrug.  IMO you've made it far worse, and if I were working on this
code I'd probably rewrite it before trying to test it.

> Also, the yes_action word is outside of the loop where (in my mind)
> it logically belongs (again the structured programming influence)
> not to mention the fact that the factored version is just plain
> easier to read.
> 
> 
>>> Have you ever needed to use something like this?
>>
>> Heavens, yes!  Hundreds of times.  There's nothing special about it.
>> It's not obscure.
> 
> You are entitled to your coding style.  But I think your premise
> that "It's possible to restructure this, but not easy." is busted.

I don't think so.  I find your solution quite unacceptable.  It's
certainly more complex.

YMMV, as usual.

Andrew.

[toc] | [prev] | [next] | [standalone]

#24851 — Re: How to abort loops and other return stack fiddling words?

On 7/29/2013 12:07 PM, Andrew Haley wrote:
> rickman<gnuarm@gmail.com>  wrote:
>> On 7/28/2013 4:37 AM, Andrew Haley wrote:
>>> rickman<gnuarm@gmail.com>   wrote:
>>>> On 7/24/2013 3:48 AM, Andrew Haley wrote:
>>>>> rickman<gnuarm@gmail.com>    wrote:
>>>>>> On 7/22/2013 12:01 PM, Anton Ertl wrote:
>>>>>>> Mark Wills<markrobertwills@yahoo.co.uk>     writes:
>>>>>>>> All of which voids the entire point - that an AGAIN loop is
>>>>>>>> *supposed* to be infinate. So if you *do* need to exit the loop,
>>>>>>>> you shouldn't be using it.
>>>>>>>
>>>>>>> Maybe that's your house style, but not everybody has to follow your
>>>>>>> house style.  In standard Forth AGAIN is just an unconditional branch
>>>>>>> backwards.  You can use it for building infinite loops, but also for
>>>>>>> other purposes.
>>>>>>
>>>>>> Do you have examples of loops with exits that are better served by AGAIN
>>>>>> than they are with UNITL or WHILE?  Are you talking about error
>>>>>> handling?   I can't think of any example where I thought it better to
>>>>>> make an infinite loop with an error exit than just using a loop with an
>>>>>> exit condition like UNTIL or WHILE.
>>>>>
>>>>> The classic case is
>>>>>
>>>>> begin
>>>>>      something
>>>>>      something_else if  maybe if  yes_action  exit  then  step  then
>>>>>      more
>>>>> again
>>>>>
>>>>> It's possible to restructure this, but not easy.
>>>>
>>>> Wow! I can't even understand what this is saying.  What are "maybe" and
>>>> "step"?  I guess I don't get any sense of why this code is written this
>>>> way.
>>>
>>> It might be stepping through some kind of data structure, with actions
>>> to be performed iff [1] a node exists and it has a particular value.
>>
>> Which word does which in the sequence above?  I need this to be a bit
>> more concrete.  Your loop runs without executing the 'step' word if
>> something_else does not return a TRUE.  So sometimes the loop is
>> stepping, other times it isn't... I find that very confusing without
>> some idea of context.  Still, it's not really a problem.
>>
>>>> begin
>>>>      something
>>>>      something_else maybe OVER AND 0= while if  step  then
>>>>      more
>>>> repeat
>>>> yes_action  ;
>>>>
>>>> Is that so complex?  Did I miss something?
>>>
>>> Yes, you did.  Perhaps it's not safe to execute MAYBE unless
>>> SOMETHING_ELSE is true.  And it's also a waste of CPU time: as soon as
>>> you've determined that SOMETHING_ELSE is false, there's no point
>>> executing MAYBE .  You can do it with multiple WHILEs, but it's no
>>> easier to understand the code.
>>
>> Ok, but that the intention is hard to tell from the code segment.  I
>> think this would be better solved by factoring.
>>
>> : loop_control
>>    something_else if maybe if FALSE else TRUE step then then
>> ;
>
> That works.  It's ugly and wasteful, though.  A fairly common design
> principle is not to test the same twice.  So, once you know something,
> you act on it.  In this case the action is to quit the loop
> immediately.  The
>
>     if FALSE else TRUE ...
>
> is a clue that something bad is going on.  You've got unnecessary
> control structures, and with a bit of refactoring you could make them
> go away.

I think you point is specious.  The control structures are *exactly* the 
control structures from your code.  If they are unnecessary or wasteful 
then the original code is as well.  Are you suggesting that this can be 
further factored or are you saying "refactor" back to the original code?


>> begin
>>      something
>>      loop_control while
>>      more
>> repeat
>> yes_action  ;
>>
>> I don't think this is overly complex and does what you needed, no?
>
> It does, but it is more complex, and it does unnecessary work.

I don't follow, what unnecessary work?  If you think this is more 
complex than your code then we are discussing tastes.  I think it is 
very clear that this code is more modular and easier to read and 
understand, that is what I mean by complexity.


> Every program can be restructored into a single WHILE loop, a ton of
> flags, and a lot of IF statements.  So, it is possible to say that you
> don't ever need to EXIT from an infinite loop.  But sometimes it
> really is easier to do so.  And the program I provided is the simplest
> classic case.

Again, the if statements are *exactly* the same as what you had but 
moved to a module and the use of EXIT and AGAIN was replaced by WHILE 
and REPEAT.  You said you had an example were an AGAIN loop was 
justified, I say you have transitioned into the domain Mark was 
referring to.


>> I think my real issue with your example is just the use of EXIT.
>> Regardless of how some people practice coding, I learned structured
>> programming in college and it made a significant impact on me.  When
>> I look at your code example, all sorts of flags pop up in my mind
>> having to do with exiting a subroutine from other than the end.  It
>> *does* make it harder to read the code (assuming there is any
>> significant code to read) and leads to errors which can be harder to
>> debug.
>
> Structured programming is just helpful advice; it's not holy writ.
> The goal is to reduce complexity.  If structured programming helps
> with that, fine.  It usually does.

I agree 100% about SP being "helpful advice".  But I have found a *very* 
few cases where it was justified to use alternate control structures.


>> I will grant you that in Forth the short code segments often used
>> make the use of EXIT easier and less trouble prone, but as you can
>> see above the factoring actually has improved the code so that the
>> main word deals with what is being done by the loop while the
>> factored word deals with how the loop is controlled.
>
> Shrug.  IMO you've made it far worse, and if I were working on this
> code I'd probably rewrite it before trying to test it.
>
>> Also, the yes_action word is outside of the loop where (in my mind)
>> it logically belongs (again the structured programming influence)
>> not to mention the fact that the factored version is just plain
>> easier to read.
>>
>>
>>>> Have you ever needed to use something like this?
>>>
>>> Heavens, yes!  Hundreds of times.  There's nothing special about it.
>>> It's not obscure.
>>
>> You are entitled to your coding style.  But I think your premise
>> that "It's possible to restructure this, but not easy." is busted.
>
> I don't think so.  I find your solution quite unacceptable.  It's
> certainly more complex.
>
> YMMV, as usual.

Ok, so you have a bias to unstructured code that you are accustomed to 
using.  Fine, but you can't justify your original statement and there is 
*no* basis for saying the factored code is more complex.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#24852 — Re: How to abort loops and other return stack fiddling words?

rickman <gnuarm@gmail.com> wrote:
> On 7/29/2013 12:07 PM, Andrew Haley wrote:
>> rickman<gnuarm@gmail.com>  wrote:
>>> On 7/28/2013 4:37 AM, Andrew Haley wrote:
>>>> rickman<gnuarm@gmail.com>   wrote:
>>>>> On 7/24/2013 3:48 AM, Andrew Haley wrote:
>>>>>> rickman<gnuarm@gmail.com>    wrote:
>>>>>>> On 7/22/2013 12:01 PM, Anton Ertl wrote:
>>>
>>>> Yes, you did.  Perhaps it's not safe to execute MAYBE unless
>>>> SOMETHING_ELSE is true.  And it's also a waste of CPU time: as soon as
>>>> you've determined that SOMETHING_ELSE is false, there's no point
>>>> executing MAYBE .  You can do it with multiple WHILEs, but it's no
>>>> easier to understand the code.
>>>
>>> Ok, but that the intention is hard to tell from the code segment.  I
>>> think this would be better solved by factoring.
>>>
>>> : loop_control
>>>    something_else if maybe if FALSE else TRUE step then then
>>> ;
>>
>> That works.  It's ugly and wasteful, though.  A fairly common design
>> principle is not to test the same twice.  So, once you know something,
>> you act on it.  In this case the action is to quit the loop
>> immediately.  The
>>
>>     if FALSE else TRUE ...
>>
>> is a clue that something bad is going on.  You've got unnecessary
>> control structures, and with a bit of refactoring you could make them
>> go away.
> 
> I think you point is specious.  The control structures are *exactly*
> the control structures from your code. 

Complexity doesn't just go away if you factor it into another word.

Let's make the point clearer by expanding the inner word where it is
called:

begin
  something
  something_else if
    maybe if  FALSE  else TRUE step then 
  then
while
  more
repeat
yes_action

versus

begin
   something
   something_else if  maybe if  yes_action  exit  then  step  then
   more
again

> If they are unnecessary or wasteful then the original code is as
> well.  Are you suggesting that this can be further factored or are
> you saying "refactor" back to the original code?

Back to the original, which does fewer tests.

> 
>>> begin
>>>      something
>>>      loop_control while
>>>      more
>>> repeat
>>> yes_action  ;
>>>
>>> I don't think this is overly complex and does what you needed, no?
>>
>> It does, but it is more complex, and it does unnecessary work.
> 
> I don't follow, what unnecessary work?  If you think this is more 
> complex than your code then we are discussing tastes.  I think it is 
> very clear that this code is more modular and easier to read and 
> understand, that is what I mean by complexity.

It is *demonstrably true* that your version does more tests.  See
above.

>>> Also, the yes_action word is outside of the loop where (in my mind)
>>> it logically belongs (again the structured programming influence)
>>> not to mention the fact that the factored version is just plain
>>> easier to read.
>>>
>>>
>>>>> Have you ever needed to use something like this?
>>>>
>>>> Heavens, yes!  Hundreds of times.  There's nothing special about it.
>>>> It's not obscure.
>>>
>>> You are entitled to your coding style.  But I think your premise
>>> that "It's possible to restructure this, but not easy." is busted.
>>
>> I don't think so.  I find your solution quite unacceptable.  It's
>> certainly more complex.
>>
>> YMMV, as usual.
> 
> Ok, so you have a bias to unstructured code that you are accustomed
> to using. 

Not exactly: I have a bias to simplicity, and IMVHO the best way to
get simplicity is by removing conditionals, not by factoring them ito
sub-words.

> Fine, but you can't justify your original statement and there is
> *no* basis for saying the factored code is more complex.

I really did explain the problem with the version you posted:

>> That works.  It's ugly and wasteful, though.  A fairly common design
>> principle is not to test the same twice.  So, once you know something,
>> you act on it.  In this case the action is to quit the loop
>> immediately.  The
>> 
>>    if FALSE else TRUE ...
>> 
>> is a clue that something bad is going on.  You've got unnecessary
>> control structures, and with a bit of refactoring you could make them
>> go away.

You asked

> Do you have examples of loops with exits that are better served by
> AGAIN than they are with UNITL or WHILE?

Of course, it's a matter of style, and of course you can always avoid
such things if you are prepared to pass flags around.

Andrew.

[toc] | [prev] | [next] | [standalone]

#24855 — Re: How to abort loops and other return stack fiddling words?

On 7/29/2013 12:54 PM, Andrew Haley wrote:
> rickman<gnuarm@gmail.com>  wrote:
>> On 7/29/2013 12:07 PM, Andrew Haley wrote:
>>> rickman<gnuarm@gmail.com>   wrote:
>>>> On 7/28/2013 4:37 AM, Andrew Haley wrote:
>>>>> rickman<gnuarm@gmail.com>    wrote:
>>>>>> On 7/24/2013 3:48 AM, Andrew Haley wrote:
>>>>>>> rickman<gnuarm@gmail.com>     wrote:
>>>>>>>> On 7/22/2013 12:01 PM, Anton Ertl wrote:
>>>>
>>>>> Yes, you did.  Perhaps it's not safe to execute MAYBE unless
>>>>> SOMETHING_ELSE is true.  And it's also a waste of CPU time: as soon as
>>>>> you've determined that SOMETHING_ELSE is false, there's no point
>>>>> executing MAYBE .  You can do it with multiple WHILEs, but it's no
>>>>> easier to understand the code.
>>>>
>>>> Ok, but that the intention is hard to tell from the code segment.  I
>>>> think this would be better solved by factoring.
>>>>
>>>> : loop_control
>>>>     something_else if maybe if FALSE else TRUE step then then
>>>> ;
>>>
>>> That works.  It's ugly and wasteful, though.  A fairly common design
>>> principle is not to test the same twice.  So, once you know something,
>>> you act on it.  In this case the action is to quit the loop
>>> immediately.  The
>>>
>>>      if FALSE else TRUE ...
>>>
>>> is a clue that something bad is going on.  You've got unnecessary
>>> control structures, and with a bit of refactoring you could make them
>>> go away.
>>
>> I think you point is specious.  The control structures are *exactly*
>> the control structures from your code.
>
> Complexity doesn't just go away if you factor it into another word.
>
> Let's make the point clearer by expanding the inner word where it is
> called:
>
> begin
>    something
>    something_else if
>      maybe if  FALSE  else TRUE step then
>    then
> while
>    more
> repeat
> yes_action
>
> versus
>
> begin
>     something
>     something_else if  maybe if  yes_action  exit  then  step  then
>     more
> again
>
>> If they are unnecessary or wasteful then the original code is as
>> well.  Are you suggesting that this can be further factored or are
>> you saying "refactor" back to the original code?
>
> Back to the original, which does fewer tests.
>
>>
>>>> begin
>>>>       something
>>>>       loop_control while
>>>>       more
>>>> repeat
>>>> yes_action  ;
>>>>
>>>> I don't think this is overly complex and does what you needed, no?
>>>
>>> It does, but it is more complex, and it does unnecessary work.
>>
>> I don't follow, what unnecessary work?  If you think this is more
>> complex than your code then we are discussing tastes.  I think it is
>> very clear that this code is more modular and easier to read and
>> understand, that is what I mean by complexity.
>
> It is *demonstrably true* that your version does more tests.  See
> above.
>
>>>> Also, the yes_action word is outside of the loop where (in my mind)
>>>> it logically belongs (again the structured programming influence)
>>>> not to mention the fact that the factored version is just plain
>>>> easier to read.
>>>>
>>>>
>>>>>> Have you ever needed to use something like this?
>>>>>
>>>>> Heavens, yes!  Hundreds of times.  There's nothing special about it.
>>>>> It's not obscure.
>>>>
>>>> You are entitled to your coding style.  But I think your premise
>>>> that "It's possible to restructure this, but not easy." is busted.
>>>
>>> I don't think so.  I find your solution quite unacceptable.  It's
>>> certainly more complex.
>>>
>>> YMMV, as usual.
>>
>> Ok, so you have a bias to unstructured code that you are accustomed
>> to using.
>
> Not exactly: I have a bias to simplicity, and IMVHO the best way to
> get simplicity is by removing conditionals, not by factoring them ito
> sub-words.
>
>> Fine, but you can't justify your original statement and there is
>> *no* basis for saying the factored code is more complex.
>
> I really did explain the problem with the version you posted:
>
>>> That works.  It's ugly and wasteful, though.  A fairly common design
>>> principle is not to test the same twice.  So, once you know something,
>>> you act on it.  In this case the action is to quit the loop
>>> immediately.  The
>>>
>>>     if FALSE else TRUE ...
>>>
>>> is a clue that something bad is going on.  You've got unnecessary
>>> control structures, and with a bit of refactoring you could make them
>>> go away.
>
> You asked
>
>> Do you have examples of loops with exits that are better served by
>> AGAIN than they are with UNITL or WHILE?
>
> Of course, it's a matter of style, and of course you can always avoid
> such things if you are prepared to pass flags around.
>
> Andrew.

I'm not interested in dissecting this ad infinitum.  I'm not measuring 
complexity by counting words, conditionals or anything else.  I'm 
considering what it takes to understand the code.  Your code had a 
rather complicated, messy use of three nested structures in a way that 
made it un-obvious all the effects and side effects that were happening. 
  All this to support the statement that there are cases where an AGAIN 
loop is a good choice.  You than made the statement "It's possible to 
restructure this, but not easy."

I showed a way to restructure the loop to use a WHILE in place of the 
EXIT allowing the loop to be a standard BEGIN WHILE REPEAT loop.  This 
simply required changing the code to encapsulate the messy bits which 
ARE the exact same logic as your code controlling the loop.  This logic 
returns a flag now partitioning the code into two parts which may be 
considered separately, the loop control code and the loop function code.

That is less complex, not because it is fewer words or fewer 
conditionals or fewer anything.  It is less complex because it is easier 
to see what is happening.  Regardless, the real point is that it *was* 
easy to restructure the code to not use the infinite loop construct 
where the logical functionality is a WHILE loop.

If you want to count conditionals and dig into the minutia of the code, 
I'm not interested.  The point was not that the restructured code would 
be fewer words or conditionals or would run faster.  The point was that 
the WHILE loop wasn't any more complex which it isn't, in fact it is 
*less* complex because it has been factored appropriately.  More 
importantly, this is not a good example of a use of the infinite loop 
with an EXIT.  It does not rise to the level of usefulness in my book.

YMMV indeed.

-- 

Rick

[toc] | [prev] | [next] | [standalone]

#24860 — Re: How to abort loops and other return stack fiddling words?

rickman <gnuarm@gmail.com> wrote:
> 

> If you want to count conditionals and dig into the minutia of the
> code, 

Of course I do: the minutiae of the code is the subject under
discussion.

> I'm not interested.  The point was not that the restructured code
> would be fewer words or conditionals or would run faster.  The point
> was that the WHILE loop wasn't any more complex which it isn't, in
> fact it is *less* complex because it has been factored
> appropriately.

That's true only if you consider that word in isolation.  In practice
you can't do that: the aggregate complexity of the solution of your
problem is what matters.

> More importantly, this is not a good example of a use of the
> infinite loop with an EXIT.  It does not rise to the level of
> usefulness in my book.

And, I suspect, there is no possible example that ever could.

> YMMV indeed.

Absolutely.

Andrew.

[toc] | [prev] | [next] | [standalone]

#24828 — Re: How to abort loops and other return stack fiddling words?

On Sunday, July 28, 2013 3:15:49 AM UTC+1, rickman wrote:
> On 7/24/2013 3:48 AM, Andrew Haley wrote:
> 
> > rickman<gnuarm@gmail.com>  wrote:
> 
> >> On 7/22/2013 12:01 PM, Anton Ertl wrote:
> 
> >>> Mark Wills<markrobertwills@yahoo.co.uk>   writes:
> 
> >>>> All of which voids the entire point - that an AGAIN loop is
> 
> >>>> *supposed* to be infinate. So if you *do* need to exit the loop,
> 
> >>>> you shouldn't be using it.
> 
> >>>
> 
> >>> Maybe that's your house style, but not everybody has to follow your
> 
> >>> house style.  In standard Forth AGAIN is just an unconditional branch
> 
> >>> backwards.  You can use it for building infinite loops, but also for
> 
> >>> other purposes.
> 
> >>
> 
> >> Do you have examples of loops with exits that are better served by AGAIN
> 
> >> than they are with UNITL or WHILE?  Are you talking about error
> 
> >> handling?   I can't think of any example where I thought it better to
> 
> >> make an infinite loop with an error exit than just using a loop with an
> 
> >> exit condition like UNTIL or WHILE.
> 
> >
> 
> > The classic case is
> 
> >
> 
> > begin
> 
> >    something
> 
> >    something_else if  maybe if  yes_action  exit  then  step  then
> 
> >    more
> 
> > again
> 
> >
> 
> > It's possible to restructure this, but not easy.
> 
> 
> 
> Wow! I can't even understand what this is saying.  What are "maybe" and 
> 
> "step"?  I guess I don't get any sense of why this code is written this 
> 
> way.
> 
> 
> 
> begin
> 
>     something
> 
>     something_else maybe OVER AND 0= while if  step  then
> 
>     more
> 
> repeat
> 
> yes_action  ;
> 
> 
> 
> Is that so complex?  Did I miss something?  Have you ever needed to use 
> 
> something like this?
> 
> 
> 
> -- 
> 
> 
> 
> Rick

Rickman,

Often these types of threads devolve from trying to help the OP with sensible advice into a Forth cock-measuring contest.

It's just not worth it.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.forth

csiph-web