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

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

Is WHILE allowed within DO .. LOOP ?

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

Contents

  Is WHILE allowed within DO .. LOOP ? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-06 16:28 +0000
    Re: Is WHILE allowed within DO .. LOOP ? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-06 17:20 +0000
    Is WHILE allowed within DO .. LOOP ? JennyB <jennybrien@googlemail.com> - 2016-01-06 09:24 -0800
      Re: Is WHILE allowed within DO .. LOOP ? Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-06 16:06 -0600
        Re: Is WHILE allowed within DO .. LOOP ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-07 08:36 +0000
          Re: Is WHILE allowed within DO .. LOOP ? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-07 13:13 +0000
            Re: Is WHILE allowed within DO .. LOOP ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-07 13:33 +0000
              Re: Is WHILE allowed within DO .. LOOP ? "Elizabeth D. Rather" <erather@forth.com> - 2016-01-07 18:42 -1000
                Re: Is WHILE allowed within DO .. LOOP ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-08 10:19 +0000
                  Re: Is WHILE allowed within DO .. LOOP ? Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-08 22:09 +0100
                    Re: Is WHILE allowed within DO .. LOOP ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-09 16:51 +0000
                      Re: Is WHILE allowed within DO .. LOOP ? Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-09 19:49 +0100
                        Re: Is WHILE allowed within DO .. LOOP ? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-10 15:44 +0000
                Re: Is WHILE allowed within DO .. LOOP ? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-08 11:22 +0000
      Re: Is WHILE allowed within DO .. LOOP ? hughaguilar96@gmail.com - 2016-01-06 22:33 -0800
        Re: Is WHILE allowed within DO .. LOOP ? Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-06 22:47 -0800
    Re: Is WHILE allowed within DO .. LOOP ? hughaguilar96@gmail.com - 2016-01-11 19:46 -0800
      Re: Is WHILE allowed within DO .. LOOP ? Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-11 22:37 -0800

#44634 — Is WHILE allowed within DO .. LOOP ?

On the recent subject of legal but unadvisable code:

I encounter the following code that cannot be compiled by ciforth,
(even with NO-SECURITY) but it can by e.g. gforth:

: S<>   ( a1 a2  -- <>? )th
   over c@ 1+ 0 do over c@ 7F and over c@ 7F and
      = while 1 dup d+
   loop   2drop false exit
   then unloop 2drop true ;

During compilation DO leaves CS: do-sys and WHILE does a CS-ROLL
It lands in THEN and fortunately we remember that we still must
discard the loop parameters.

The CS-ROLL works fine within BEGIN WHILE IF THEN REPEAT because
a CS item is two stack items in those cases.

However my do-sys consists of 3 stack items and the CS-ROLL plays
havock, i.e. a segmentation fault.

Was it the intention of the standard that do-sys can be subjected
to a CS-ROLL in order to allow the above code? Which means that
all other control-stack-items have to be padded with one dummy item
in my implementation?

(I agree with Julian Fondren that it is better to allow unstructured
jumps rather than this.)

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [next] | [standalone]

#44636

On 06/01/2016 16:28, Albert van der Horst wrote:
> On the recent subject of legal but unadvisable code:
>
> I encounter the following code that cannot be compiled by ciforth,
> (even with NO-SECURITY) but it can by e.g. gforth:
>
> : S<>   ( a1 a2  -- <>? )th
>     over c@ 1+ 0 do over c@ 7F and over c@ 7F and
>        = while 1 dup d+
>     loop   2drop false exit
>     then unloop 2drop true ;
>
> During compilation DO leaves CS: do-sys and WHILE does a CS-ROLL
> It lands in THEN and fortunately we remember that we still must
> discard the loop parameters.
>
> The CS-ROLL works fine within BEGIN WHILE IF THEN REPEAT because
> a CS item is two stack items in those cases.
>
> However my do-sys consists of 3 stack items and the CS-ROLL plays
> havock, i.e. a segmentation fault.
>
> Was it the intention of the standard that do-sys can be subjected
> to a CS-ROLL in order to allow the above code? Which means that
> all other control-stack-items have to be padded with one dummy item
> in my implementation?
>

I don't think it is allowed by the standard since 15.6.2.1020 specifies 
that each item on the control stack within the range of the CS-ROLL 
"shall be an orig or dest". A do-sys is clearly neither and so is not 
permitted.

-- 
Gerry

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

#44637

This is not meant to be portable. It only works if do-sys happens to be the right size.

It's also needlessly complex. The cleaner (and portable) way to do this sort of thing is:

     DO
          IF ... UNLOOP EXIT THEN
        ...
     LOOP
     ...

     ;

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

#44642

JennyB <jennybrien@googlemail.com> wrote:

> This is not meant to be portable. It only works if do-sys happens to
> be the right size.
> 
> It's also needlessly complex. The cleaner (and portable) way to do
> this sort of thing is:
> 
>     DO
>          IF ... UNLOOP EXIT THEN
>        ...
>     LOOP
>     ...
> 
>     ;

The caller usually needs to know whether the loop was exited early.
So, the above would likely be

: barf ( - t)
     do
          if ... unloop true ( we found something)  exit then
        ...
     loop
     ...
 
     false ( we didn't find anything) ;

and the caller would have to do 

     barf if  found-action  else  not-found-action  then

I hate passing flags around like that. I prefer

    do  ... 
        while
        ... 
    loop
        not-found-action
    else
        found-action  unloop
    then

Andrew.

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

#44655

Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>JennyB <jennybrien@googlemail.com> wrote:
>
>> This is not meant to be portable. It only works if do-sys happens to
>> be the right size.
>> 
>> It's also needlessly complex. The cleaner (and portable) way to do
>> this sort of thing is:
>> 
>>     DO
>>          IF ... UNLOOP EXIT THEN
>>        ...
>>     LOOP
>>     ...
>> 
>>     ;
>
>The caller usually needs to know whether the loop was exited early.
>So, the above would likely be
>
>: barf ( - t)
>     do
>          if ... unloop true ( we found something)  exit then
>        ...
>     loop
>     ...
> 
>     false ( we didn't find anything) ;
>
>and the caller would have to do 
>
>     barf if  found-action  else  not-found-action  then
>
>I hate passing flags around like that. I prefer
>
>    do  ... 
>        while
>        ... 
>    loop
>        not-found-action
>    else
>        found-action  unloop
>    then

Or you can write it in standard Forth as

do
  ... if ... found-action unloop exit then
  ... loop
not-found-action

In any case, the word that spawned this discussion actually returns
true or false, so the technique you defend here does not prevent that.

It also and has no control flow join in the end, so it could be
converted into standard Forth without any drawback.  Makes me wonder
why it was written in this way in the first place.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44662

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:

>Andrew Haley <andrew29@littlepinkcloud.invalid> writes:
>>JennyB <jennybrien@googlemail.com> wrote:
>>
>>> This is not meant to be portable. It only works if do-sys happens to
>>> be the right size.
>>>
>>> It's also needlessly complex. The cleaner (and portable) way to do
>>> this sort of thing is:
>>>
>>>     DO
>>>          IF ... UNLOOP EXIT THEN
>>>        ...
>>>     LOOP
>>>     ...
>>>
>>>     ;
>>
>>The caller usually needs to know whether the loop was exited early.
>>So, the above would likely be
>>
>>: barf ( - t)
>>     do
>>          if ... unloop true ( we found something)  exit then
>>        ...
>>     loop
>>     ...
>>
>>     false ( we didn't find anything) ;
>>
>>and the caller would have to do
>>
>>     barf if  found-action  else  not-found-action  then
>>
>>I hate passing flags around like that. I prefer
>>
>>    do  ...
>>        while
>>        ...
>>    loop
>>        not-found-action
>>    else
>>        found-action  unloop
>>    then

>Or you can write it in standard Forth as

>do
>  ... if ... found-action unloop exit then
>  ... loop
>not-found-action

>In any case, the word that spawned this discussion actually returns
>true or false, so the technique you defend here does not prevent that.

>It also and has no control flow join in the end, so it could be
>converted into standard Forth without any drawback.  Makes me wonder
>why it was written in this way in the first place.

The author may have reasons, it is very similar to a structured
assembler routine.
The question is: ciforth doesn't grock this, ( it does in an
experimental version where I added a screen with -pedantic-.)

The question remains: is the do-sys that is left on the control
flow stack a valid object to be manipulated by CS-ROLL.

This is a language lwayer question. As far as I am concerned
the style issue is settled before it is even posed.

>- anton
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#44664

Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>The question remains: is the do-sys that is left on the control
>flow stack a valid object to be manipulated by CS-ROLL.

Someone already ansered this question: It is not.  What about the
specification of CS-ROLL makes you think that it might be guaranteed
to work with do-sys?

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44674

On 1/7/16 3:33 AM, Anton Ertl wrote:
> Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> The question remains: is the do-sys that is left on the control
>> flow stack a valid object to be manipulated by CS-ROLL.
>
> Someone already ansered this question: It is not.  What about the
> specification of CS-ROLL makes you think that it might be guaranteed
> to work with do-sys?

Right. The stack specification for CS-ROLL is:
( C: origu | destu origu-1 | destu-1 . . . orig0 | dest0 – –
		origu-1 | destu-1 . . . orig0 | dest0 origu | destu )

In other words, only origs and dests, no do-sys. The class of finite 
loop words (DO, LOOP, and their relatives) are different from the 
indefinite loop class (BEGIN, WHILE, UNTIL, and relatives). You can't 
mix and match. The reason is that not only that a do-sys may be a 
different size from origs and dests, but more importantly, the DO ... 
LOOP family of words has stuff on the Return Stack, while the indefinite 
loop words do not.

Cheers,
Elizabeth

-- 
==================================================
Elizabeth D. Rather   (US & Canada)   800-55-FORTH
FORTH Inc.                         +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com

"Forth-based products and Services for real-time
applications since 1973."
==================================================

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

#44682

"Elizabeth D. Rather" <erather@forth.com> writes:
>The reason is that not only that a do-sys may be a 
>different size from origs and dests, but more importantly, the DO ... 
>LOOP family of words has stuff on the Return Stack, while the indefinite 
>loop words do not.

Yes, although that would not really be a problem with regards to the
specification: If we allow CS-ROLL to also deal with do-sys, and a
program makes use of that, there is the loop-sys around at run-time on
the irregular exit from the counted loop, and just like for EXIT
inside the counted loop, the program has to get rid of that with
UNLOOP.

Hmm, another way to deal with the loop-sys would be to consume it in
another counted loop, e.g.,

do ... while ... loop
...
do ... [ 1 cs-roll ] then ... loop

Here the WHILE jumps to the THEN in the other counted loop.  But given
that this should work in Gforth and, to my knowledge, has not been
used, it will probably not be a frequent construct.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44715

Anton Ertl wrote:

> Here the WHILE jumps to the THEN in the other counted loop.  But given
> that this should work in Gforth and, to my knowledge, has not been
> used, it will probably not be a frequent construct.

Works, has been used:

: capscomp  ( c_addr1 u c_addr2 -- n )
 swap bounds
 ?DO  dup c@ I c@ <>
     IF  dup c@ toupper I c@ toupper =
     ELSE  true  THEN  WHILE  1+  LOOP  drop 0
 ELSE  c@ toupper I c@ toupper - unloop  THEN  sgn ;

(in history.fs)

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#44726

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> Here the WHILE jumps to the THEN in the other counted loop.  But given
>> that this should work in Gforth and, to my knowledge, has not been
>> used, it will probably not be a frequent construct.
>
>Works, has been used:
>
>: capscomp  ( c_addr1 u c_addr2 -- n )
> swap bounds
> ?DO  dup c@ I c@ <>
>     IF  dup c@ toupper I c@ toupper =
>     ELSE  true  THEN  WHILE  1+  LOOP  drop 0
> ELSE  c@ toupper I c@ toupper - unloop  THEN  sgn ;

This contains only one DO...LOOP, so it is not a case of using WHILE
to jump from one DO...LOOP into another one.

This word is crying out for cleanup, however, and the WHILE out of the
DO..LOOP is pretty low on the priority list.  Well, let me have a try:

The stack effect looks suspicious, but I'll ignore that for now.

: capscomp  ( c_addr1 u c_addr2 -- -1|0|1 )
  swap bounds ?do
    dup c@ toupper i c@ toupper - dup if
      sgn unloop exit then
    1+ loop
  drop 0 ;

(untested) Simpler and cleaner.  Not sure how slow TOUPPER is, it
might also be faster.  It certainly saves a bit by not applying SGN to
0.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44729

Anton Ertl wrote:

> The stack effect looks suspicious, but I'll ignore that for now.
> 
> : capscomp  ( c_addr1 u c_addr2 -- -1|0|1 )
> swap bounds ?do
> dup c@ toupper i c@ toupper - dup if
> sgn unloop exit then
> 1+ loop
> drop 0 ;
> 
> (untested) Simpler and cleaner.  Not sure how slow TOUPPER is, it
> might also be faster.  It certainly saves a bit by not applying SGN to
> 0.

If you don't have sgn on 0, you could unfold it; sgn on non-0 is pretty 
easy.  Tested:

: capscomp  ( c_addr1 u c_addr2 -- -1|0|1 )
    swap bounds ?do
	count toupper i c@ toupper - ?dup-if
	    nip 0< 2* 1+ unloop exit then
    loop
    drop 0 ;

Since this is for tab completion, I suppose that it's not really that 
performance critical.  The -1|0|1 is probably overblow, compare returns an n 
as well.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ*
http://bernd-paysan.de/

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

#44739

Bernd Paysan <bernd.paysan@gmx.de> writes:
>Anton Ertl wrote:
>
>> The stack effect looks suspicious, but I'll ignore that for now.
>> 
>> : capscomp  ( c_addr1 u c_addr2 -- -1|0|1 )
>> swap bounds ?do
>> dup c@ toupper i c@ toupper - dup if
>> sgn unloop exit then
>> 1+ loop
>> drop 0 ;
>> 
>> (untested) Simpler and cleaner.  Not sure how slow TOUPPER is, it
>> might also be faster.  It certainly saves a bit by not applying SGN to
>> 0.
>
>If you don't have sgn on 0, you could unfold it; sgn on non-0 is pretty 
>easy.  Tested:
>
>: capscomp  ( c_addr1 u c_addr2 -- -1|0|1 )
>    swap bounds ?do
>	count toupper i c@ toupper - ?dup-if
>	    nip 0< 2* 1+ unloop exit then
>    loop
>    drop 0 ;
>
>Since this is for tab completion, I suppose that it's not really that 
>performance critical.  The -1|0|1 is probably overblow, compare returns an n 
>as well.

Yes.  If you want it, and since performance is not paramount, using
SGN is clearer than the optimized inlined version (as well as shorter
in the current Gforth implementation).  Using C@+ is clearer than
using COUNT.

- 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 2015: http://www.rigwit.co.uk/EuroForth2015/

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

#44687

"Elizabeth D. Rather" <erather@forth.com> writes:

>On 1/7/16 3:33 AM, Anton Ertl wrote:
>> Albert van der Horst <albert@spenarnc.xs4all.nl> writes:
>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> The question remains: is the do-sys that is left on the control
>>> flow stack a valid object to be manipulated by CS-ROLL.
>>
>> Someone already ansered this question: It is not.  What about the
>> specification of CS-ROLL makes you think that it might be guaranteed
>> to work with do-sys?

>Right. The stack specification for CS-ROLL is:
>( C: origu | destu origu-1 | destu-1 . . . orig0 | dest0 – –
>               origu-1 | destu-1 . . . orig0 | dest0 origu | destu )

>In other words, only origs and dests, no do-sys. The class of finite
>loop words (DO, LOOP, and their relatives) are different from the
>indefinite loop class (BEGIN, WHILE, UNTIL, and relatives). You can't
>mix and match. The reason is that not only that a do-sys may be a
>different size from origs and dests, but more importantly, the DO ...
>LOOP family of words has stuff on the Return Stack, while the indefinite
>loop words do not.

I missed the distinction between and "orig" and a "dosys".
So now I can go back to the author and ask for a change because it is
not standard.

You point out the two differences.
I've now made a loadable extension, where the size of
do-sys and orig are the same. It basically redefines all control words,
which wastes another whole screen. With this the construction it
works on ciforth.

I don't think the loop parameters on the return stack are a problem
for the compiler (they are a pitfall for the programmer)

After jumping out of the DO LOOP using WHILE to a THEN
it is sufficient to place an UNLOOP there. At least this
works in the case of the example word I posted.
Otherwise it is hard to imagine how the idio,
   IF ... UNLOOP EXIT THEN
could work in a loop.

>Cheers,
>Elizabeth

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

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

#44650

On Wednesday, January 6, 2016 at 10:24:06 AM UTC-7, JennyB wrote:
> This is not meant to be portable. It only works if do-sys happens to be the right size.
> 
> It's also needlessly complex. The cleaner (and portable) way to do this sort of thing is:
> 
>      DO
>           IF ... UNLOOP EXIT THEN
>         ...
>      LOOP
>      ...
> 
>      ;

Such code as Albert showed is unclean! Who writes this stuff??? 

I think there are too many people who think of Forth as a puzzle factory --- figuring out what their code does is more difficult than solving a Sudoku puzzle --- they just aren't thinking of Forth as being a practical language for writing programs that do something useful.

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

#44651

> Such code as Albert showed is unclean! Who writes this stuff??? 
> 
Unclean?
Coding horror.

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

#44775

On Wednesday, January 6, 2016 at 9:28:45 AM UTC-7, Albert van der Horst wrote:
> Was it the intention of the standard that do-sys can be subjected
> to a CS-ROLL in order to allow the above code? Which means that
> all other control-stack-items have to be padded with one dummy item
> in my implementation?

In my FloatForth I have a control-flow stack that is separate from the data stack. I make it wide enough to hold any kind of data, and data that are smaller than that have to be padded to make them the same size as everything else. This way CS-DUP CS-SWAP CS-ROLL etc. all work on anything.

This doesn't at all imply that I want people to write coding horrors such as Albert showed. This kind of thing would be caught and would result in a compile-time abort with a helpful error message. Each kind of control-flow data is tagged and everything that works on any of this data will check that it has the right kind of data.

For the most part I will use quotations for iteration (as shown in STUNDURD.TXT) --- I won't really have a lot of control-flow structures --- I may just have BEGIN BREAK REPEAT (the BREAK can be used inside of nested IF ELSE THEN constructs). I might have CONTINUE also --- I haven't decided about that one --- I suppose, as Raimond says: "Why not?"

I'm not going to have DO loops --- there are a lot of good reasons why not for that clunker.

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

#44776

marți, 12 ianuarie 2016, 05:46:12 UTC+2, hughag...@gmail.com a scris:
> On Wednesday, January 6, 2016 at 9:28:45 AM UTC-7, Albert van der Horst wrote:
> > Was it the intention of the standard that do-sys can be subjected
> > to a CS-ROLL in order to allow the above code? Which means that
> > all other control-stack-items have to be padded with one dummy item
> > in my implementation?
> 
> In my FloatForth I have a control-flow stack that is separate from the data stack. I make it wide enough to hold any kind of data, and data that are smaller than that have to be padded to make them the same size as everything else. This way CS-DUP CS-SWAP CS-ROLL etc. all work on anything.
> 
> This doesn't at all imply that I want people to write coding horrors such as Albert showed. This kind of thing would be caught and would result in a compile-time abort with a helpful error message. Each kind of control-flow data is tagged and everything that works on any of this data will check that it has the right kind of data.
> 
> For the most part I will use quotations for iteration (as shown in STUNDURD.TXT) --- I won't really have a lot of control-flow structures --- I may just have BEGIN BREAK REPEAT (the BREAK can be used inside of nested IF ELSE THEN constructs). I might have CONTINUE also --- I haven't decided about that one --- I suppose, as Raimond says: "Why not?"
> 
> I'm not going to have DO loops --- there are a lot of good reasons why not for that clunker.

8th has REPEAT ... AGAIN and REPEAT ... WHILE with BREAK
REPEAT seems to me a better naming than BEGIN.
REPEAT ... AGAIN
REPEAT ... UNTIL
REPEAT ... WHILE
Or LOOP:
LOOP ... AGAIN
LOOP ... UNTIL
LOOP ... WHILE
These are very clean looping structures with a possible decision at the
end only (UNTIL, WHILE) but with any number of BREAKs or CONTINUEs inside.
And with a very clean and readable coding in an application.

As for the DO loops (what an ugly name for a loop! forth has only ugly names
for loops: BEGIN loops and DO loops :) a honest simple counted loop is
the FOR ... NEXT with a down counting index on the return stack. I found
it incredibile usefull so many times, and usually without needing the
index.

I would implement:
REPEAT ... AGAIN with BREAK and CONTINUE
FOR ... NEXT
UNTIL and WHILE can be implemented as compiler macros for user convenience,
in terms of BREAK/CONTINUE.

[toc] | [prev] | [standalone]

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

csiph-web