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

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

Loop structures

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

Contents

   Loop structures kenney@cix.compulink.co.uk - 2013-02-06 03:55 -0600
    Re: Loop structures Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-06 04:24 -0600
    Re: Loop structures Pablo Hugo Reda <pabloreda@gmail.com> - 2013-02-06 05:38 -0800
    Re: Loop structures Hugh Aguilar <hughaguilar96@yahoo.com> - 2013-02-06 10:43 -0800
      Re: Loop structures "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2013-02-08 03:46 -0500
    Re: Loop structures awegel@arcor.de (Alex Wegel) - 2013-02-06 20:19 +0100
      Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-07 20:27 +1100
        Re: Loop structures Coos Haak <chforth@hccnet.nl> - 2013-02-07 17:03 +0100
          Re: Loop structures awegel@arcor.de (Alex Wegel) - 2013-02-08 00:43 +0100
            Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-09 20:52 +1100
              Re: Loop structures Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-09 18:05 -0600
                Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-10 11:48 +1100
              Re: Loop structures awegel@arcor.de (Alex Wegel) - 2013-02-11 01:41 +0100
                Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-11 12:56 +1100
                  Re: Loop structures "Elizabeth D. Rather" <erather@forth.com> - 2013-02-10 17:54 -1000
                    Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-12 15:11 +1100
                      Re: Loop structures Andrew Haley <andrew29@littlepinkcloud.invalid> - 2013-02-13 09:49 -0600
                  Re: Loop structures Mark Wills <forthfreak@gmail.com> - 2013-02-11 23:32 -0800
                    Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-13 12:34 +1100
                      Re: Loop structures "Elizabeth D. Rather" <erather@forth.com> - 2013-02-12 15:49 -1000
                        Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-13 14:48 +1100
                          Re: Loop structures Alex McDonald <blog@rivadpm.com> - 2013-02-12 23:02 -0800
                            Re: Loop structures Alex McDonald <blog@rivadpm.com> - 2013-02-12 23:29 -0800
                            Re: Loop structures albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-13 13:35 +0000
                              Re: Loop structures Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-13 15:17 +0100
                              Re: Loop structures Alex McDonald <blog@rivadpm.com> - 2013-02-13 09:01 -0800
                                Re: Loop structures albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-13 20:22 +0000
                                  Re: Loop structures anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-14 16:29 +0000
                                    Re: Loop structures albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-14 18:41 +0000
                                      Re: Loop structures Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-14 21:44 +0100
                                        Re: Loop structures albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-14 21:06 +0000
                                          Re: Loop structures Bernd Paysan <bernd.paysan@gmx.de> - 2013-02-14 23:51 +0100
                                            Re: Loop structures mhx@iae.nl (Marcel Hendrix) - 2013-02-15 00:56 +0200
                                              Re: Loop structures anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-15 09:53 +0000
                                                Re: Loop structures m.a.m.hendrix@tue.nl - 2013-02-15 03:36 -0800
                                      Re: Loop structures anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-02-15 09:44 +0000
                                  Re: Loop structures Lars Brinkhoff <lars.spam@nocrew.org> - 2013-03-04 13:04 +0100
                                    Re: Loop structures albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-03-04 13:22 +0000
                            Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-15 13:09 +1100
                              Re: Loop structures Alex McDonald <blog@rivadpm.com> - 2013-02-14 19:21 -0800
                              Re: Loop structures albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-02-15 13:01 +0000
                                Re: Loop structures Alex McDonald <blog@rivadpm.com> - 2013-02-15 07:51 -0800
                          Re: Loop structures Brad Eckert <hwfwguy@gmail.com> - 2013-02-13 10:51 -0800
                            Re: Loop structures "Ed" <invalid@nospam.com> - 2013-02-15 13:11 +1100
                              Re: Loop structures "Elizabeth D. Rather" <erather@forth.com> - 2013-02-14 21:31 -1000
                      Re: Loop structures Mark Wills <forthfreak@gmail.com> - 2013-02-13 00:18 -0800
                        Re: Loop structures alberto@hal-pc.org - 2013-02-13 14:27 +0000
                          Re: Loop structures Mark Wills <forthfreak@gmail.com> - 2013-02-13 07:08 -0800
                            Re: Loop structures m.a.m.hendrix@tue.nl - 2013-02-13 08:23 -0800
                              Re: Loop structures stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-13 17:32 +0000
                                Re: Loop structures Mark Wills <forthfreak@gmail.com> - 2013-02-13 23:17 -0800
                                  Re: Loop structures stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-14 10:53 +0000
                                    Re: Loop structures stephenXXX@mpeforth.com (Stephen Pelc) - 2013-02-14 13:42 +0000
                                    Re: Loop structures "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-02-14 21:25 -0800
                                  Re: Loop structures "Clyde W. Phillips Jr." <cwpjr02@gmail.com> - 2013-02-14 21:18 -0800
                              Re: Loop structures Mark Wills <forthfreak@gmail.com> - 2013-02-13 23:15 -0800
                        Re: Loop structures mhx@iae.nl (Marcel Hendrix) - 2013-02-14 22:08 +0200
                          Re: Loop structures Mark Wills <forthfreak@gmail.com> - 2013-02-14 22:53 -0800
                  Re: Loop structures awegel@arcor.de (Alex Wegel) - 2013-02-12 16:00 +0100
    Re: Loop structures kenney@cix.compulink.co.uk - 2013-02-13 03:49 -0600

Page 1 of 3  [1] 2 3  Next page →

#19503 — Loop structures

 The discussions about do lops triggered an interest in loop structures. 
I can think of three
 "for-next" unconditional
 "repeat-until" conditional is checked at the end of each run through 
the loop as a result the code will be run at least once
 
 "While-next" conditional is checked at the start of each run through 
the loop
 
 As far as I can tell any other structures are variants of the above 
with the possibility of multiple exits is this correct?
 
 Ken Young

[toc] | [next] | [standalone]

#19504

kenney@cix.compulink.co.uk wrote:
> The discussions about do lops triggered an interest in loop structures. 
> I can think of three
> "for-next" unconditional
> "repeat-until" conditional is checked at the end of each run through 
> the loop as a result the code will be run at least once
> 
> "While-next" conditional is checked at the start of each run through 
> the loop
> 
> As far as I can tell any other structures are variants of the above 
> with the possibility of multiple exits is this correct?

Yes, I think so.  One minor nit: the "while-next" conditional has a
test in the middle of the loop, not the start.

In essence, there are only relly two kinds of loops: bounded and
unbounded.

Andrew.

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

#19507

El miércoles, 6 de febrero de 2013 06:55:44 UTC-3, ken...@cix.compulink.co.uk  escribió:
> The discussions about do lops triggered an interest in loop structures. 
> 
> I can think of three
> 
>  "for-next" unconditional
> 
>  "repeat-until" conditional is checked at the end of each run through 
> 
> the loop as a result the code will be run at least once
> 
>  
> 
>  "While-next" conditional is checked at the start of each run through 
> 
> the loop
> 
>  
> 
>  As far as I can tell any other structures are variants of the above 
> 
> with the possibility of multiple exits is this correct?
> 
>  
> 
>  Ken Young

for-next have conditional !!

I name control structures adding the if and if-else.

I define this control structures and not need more. 
?? mean conditional (make a flag for jump)
?? ( words ) ---> IF
?? ( words )( wordsb ) ---> IF-ELSE
( words ?? )( wordsb ) ---> WHILE 
( words ?? ) ---> UNTIL
( words ) ---> REPEAT forever

for-next can be code..

 0 ( 10 <? )( .... 1+ ) drop | count from 0 to 9..

I can exit in any place with ";" (need take care about stack for sure)
multiple exits it ok.

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

#19514

On Feb 6, 2:55 am, ken...@cix.compulink.co.uk wrote:
>  The discussions about do lops triggered an interest in loop structures.
> I can think of three
>  "for-next" unconditional
>  "repeat-until" conditional is checked at the end of each run through
> the loop as a result the code will be run at least once
>
>  "While-next" conditional is checked at the start of each run through
> the loop
>
>  As far as I can tell any other structures are variants of the above
> with the possibility of multiple exits is this correct?
>
>  Ken Young

Yes, that pretty much covers it.

I had FOR NEXT in MFX, as well as DO. I don't think I will support
either this time. I will have TIMES, which is a simplified version of
FOR NEXT that always counts down to 0 rather than going either up or
down and going to an arbitrary limit.

Also, as Andrew mentioned, the WHILE is in the middle not the
beginning.

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

#19543

"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message
news:50e33034-7e5b-47e7-8c65-b3ab71669044@z9g2000vbx.googlegroups.com...

> I had FOR NEXT in MFX, as well as DO. I don't think I
> will support either this time. I will have TIMES, which
> is a simplified version of FOR NEXT that always counts
> down to 0 rather than going either up or down and going
> to an arbitrary limit.

That just allocated one more register ... another one for zero ...
three for top of stack items ... two for stack pointers ...
You're going to run out of registers on 64-bit x86!  ;-)

Do you plan a compatibility package with definitions for, say DO,
FOR, NEXT, etc, in terms of TIMES?

Do you see any contradiction in you providing numerous stacks:
float, integer, loop, control etc., i.e., "generous" or "liberal",
but at the same you're limiting the language to the minimum, i.e.,
"constrained" or "conservative".

Lol,


RP

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

#19516

<kenney@cix.compulink.co.uk> wrote:

>  The discussions about do lops triggered an interest in loop structures.
> I can think of three
>  "for-next" unconditional
>  "repeat-until" conditional is checked at the end of each run through
> the loop as a result the code will be run at least once
>  
>  "While-next" conditional is checked at the start of each run through
> the loop
>  
>  As far as I can tell any other structures are variants of the above 
> with the possibility of multiple exits is this correct?

No, there's also "forever", or -in forth- "begin ... again".

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

#19522

Alex Wegel wrote:
> <kenney@cix.compulink.co.uk> wrote:
>
> >  The discussions about do lops triggered an interest in loop structures.
> > I can think of three
> >  "for-next" unconditional
> >  "repeat-until" conditional is checked at the end of each run through
> > the loop as a result the code will be run at least once
> >
> >  "While-next" conditional is checked at the start of each run through
> > the loop
> >
> >  As far as I can tell any other structures are variants of the above
> > with the possibility of multiple exits is this correct?
>
> No, there's also "forever", or -in forth- "begin ... again".

AGAIN is optional in ANS-Forth as infinite loops are readily implemented
using indefinite loops e.g.  BEGIN .. 0 UNTIL.

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

#19524

Op Thu, 7 Feb 2013 20:27:39 +1100 schreef Ed:

> Alex Wegel wrote:
>> <kenney@cix.compulink.co.uk> wrote:
>>
>>>  The discussions about do lops triggered an interest in loop structures.
>>> I can think of three
>>>  "for-next" unconditional
>>>  "repeat-until" conditional is checked at the end of each run through
>>> the loop as a result the code will be run at least once
>>>
>>>  "While-next" conditional is checked at the start of each run through
>>> the loop
>>>
>>>  As far as I can tell any other structures are variants of the above
>>> with the possibility of multiple exits is this correct?
>>
>> No, there's also "forever", or -in forth- "begin ... again".
> 
> AGAIN is optional in ANS-Forth as infinite loops are readily implemented
> using indefinite loops e.g.  BEGIN .. 0 UNTIL.

Does it matter? The OP mentioned REPEAT .. UNTIL. That's not Forth either.

-- 
Coos

CHForth, 16 bit DOS applications
http://home.hccnet.nl/j.j.haak/forth.html 

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

#19538

Coos Haak <chforth@hccnet.nl> wrote:

> Op Thu, 7 Feb 2013 20:27:39 +1100 schreef Ed:
> 
> > Alex Wegel wrote:
> >> <kenney@cix.compulink.co.uk> wrote:
> >>
> >>>  The discussions about do lops triggered an interest in loop structures.
> >>> I can think of three
> >>>  "for-next" unconditional
> >>>  "repeat-until" conditional is checked at the end of each run through
> >>> the loop as a result the code will be run at least once
> >>>
> >>>  "While-next" conditional is checked at the start of each run through
> >>> the loop
> >>>
> >>>  As far as I can tell any other structures are variants of the above
> >>> with the possibility of multiple exits is this correct?
> >>
> >> No, there's also "forever", or -in forth- "begin ... again".
> > 
> > AGAIN is optional in ANS-Forth as infinite loops are readily implemented
> > using indefinite loops e.g.  BEGIN .. 0 UNTIL.
> 
> Does it matter? The OP mentioned REPEAT .. UNTIL. That's not Forth either.

Well - i think AGAIN being optional in ans forth should be proof enough
that it actually *is* forth, and that it has been for quite a while ;-)

BTW: It is the most basic looping construct, and often the basis of
(high-level definitions of) the words UNTIL and REPEAT. The OP didn't
mention "no exits", so this wasn't covered.

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

#19573

Alex Wegel wrote:
> Coos Haak <chforth@hccnet.nl> wrote:
>
> > Op Thu, 7 Feb 2013 20:27:39 +1100 schreef Ed:
> >
> > > Alex Wegel wrote:
> > >> <kenney@cix.compulink.co.uk> wrote:
> > >>
> > >>>  The discussions about do lops triggered an interest in loop structures.
> > >>> I can think of three
> > >>>  "for-next" unconditional
> > >>>  "repeat-until" conditional is checked at the end of each run through
> > >>> the loop as a result the code will be run at least once
> > >>>
> > >>>  "While-next" conditional is checked at the start of each run through
> > >>> the loop
> > >>>
> > >>>  As far as I can tell any other structures are variants of the above
> > >>> with the possibility of multiple exits is this correct?
> > >>
> > >> No, there's also "forever", or -in forth- "begin ... again".
> > >
> > > AGAIN is optional in ANS-Forth as infinite loops are readily implemented
> > > using indefinite loops e.g.  BEGIN .. 0 UNTIL.
> >
> > Does it matter? The OP mentioned REPEAT .. UNTIL. That's not Forth either.
>
> Well - i think AGAIN being optional in ans forth should be proof enough
> that it actually *is* forth, and that it has been for quite a while ;-)
>
> BTW: It is the most basic looping construct, and often the basis of
> (high-level definitions of) the words UNTIL and REPEAT. The OP didn't
> mention "no exits", so this wasn't covered.

My understanding is that infinite loops are not counted among the classic
looping constructs - hence my comment.  It is true AGAIN is useful as a
primitive but generally it is not required.

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

#19596

Ed <invalid@nospam.com> wrote:

> It is true AGAIN is useful as a primitive but generally it is not
> required.

Not required?  It's classic Forth design to structure a control task
as

   begin  stop ( wait for an interrupt )  process  again

Andrew.

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

#19600

Andrew Haley wrote:
> Ed <invalid@nospam.com> wrote:
>
> > It is true AGAIN is useful as a primitive but generally it is not
> > required.
>
> Not required?  It's classic Forth design to structure a control task
> as
>
>    begin  stop ( wait for an interrupt )  process  again
>
> Andrew.

ANS said AGAIN was not required and I agree with them.

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

#19618

Ed <invalid@nospam.com> wrote:

> Alex Wegel wrote:
> > Coos Haak <chforth@hccnet.nl> wrote:
> >

...

> My understanding is that infinite loops are not counted among the classic
> looping constructs 

That must be because they're still counting.

>  - hence my comment. 

Thanks for clarifying this.

But you *do* agree that infinite loops exist (even in forth), and that
they differ from the other constructs having been mentioned?

> It is true AGAIN is useful as a primitive

And i agree 200% on the usefulness ;-)

(AGAIN is not a primitive though.)

> but generally it is not required.

My original point wasn't so much about AGAIN, more about recognizing the
infinite loop as a basic looping construct in general.

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

#19623

Alex Wegel wrote:
> ...
> But you *do* agree that infinite loops exist (even in forth), and that
> they differ from the other constructs having been mentioned?
...
> My original point wasn't so much about AGAIN, more about recognizing the
> infinite loop as a basic looping construct in general.

None of the CS texts I've read mention infinite loops as a fundamental
construct.  When they're discussed they're described in terms of the
classic loops, which in Forth would be BEGIN... 0 UNTIL or BEGIN...
1 WHILE...REPEAT.

"Starting FORTH" (first ed.) talks about creating infinite loops with
BEGIN...0 UNTIL.  AFAIK AGAIN is not referenced anywhere.

When this topic came up before some folks pointed out other
languages would optimize the equivalent of 0 UNTIL into an AGAIN.
Having a specific construct for infinite loops in these languages
would thus be redundant.

Some folks say BEGIN... AGAIN is faster that BEGIN...0 UNTIL
but I can't think of a scenario where this would be true.

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

#19625

On 2/10/13 3:56 PM, Ed wrote:
> Alex Wegel wrote:
>> ...
>> But you *do* agree that infinite loops exist (even in forth), and that
>> they differ from the other constructs having been mentioned?
> ...
>> My original point wasn't so much about AGAIN, more about recognizing the
>> infinite loop as a basic looping construct in general.
>
> None of the CS texts I've read mention infinite loops as a fundamental
> construct.  When they're discussed they're described in terms of the
> classic loops, which in Forth would be BEGIN... 0 UNTIL or BEGIN...
> 1 WHILE...REPEAT.
>
> "Starting FORTH" (first ed.) talks about creating infinite loops with
> BEGIN...0 UNTIL.  AFAIK AGAIN is not referenced anywhere.
>
> When this topic came up before some folks pointed out other
> languages would optimize the equivalent of 0 UNTIL into an AGAIN.
> Having a specific construct for infinite loops in these languages
> would thus be redundant.
>
> Some folks say BEGIN... AGAIN is faster that BEGIN...0 UNTIL
> but I can't think of a scenario where this would be true.

Well, at least in a traditional Forth, UNTIL performs a test, which 
AGAIN does not. An optimizer would handle it properly, as in the "other 
languages," but not all Forths.

It's certainly not a big deal, though. AGAIN is just a convenience, and 
in some circumstances a minor optimization.

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]

#19663

Elizabeth D. Rather wrote:
> On 2/10/13 3:56 PM, Ed wrote:
> > ...
> > "Starting FORTH" (first ed.) talks about creating infinite loops with
> > BEGIN...0 UNTIL.  AFAIK AGAIN is not referenced anywhere.
> >
> > When this topic came up before some folks pointed out other
> > languages would optimize the equivalent of 0 UNTIL into an AGAIN.
> > Having a specific construct for infinite loops in these languages
> > would thus be redundant.
> >
> > Some folks say BEGIN... AGAIN is faster that BEGIN...0 UNTIL
> > but I can't think of a scenario where this would be true.
>
> Well, at least in a traditional Forth, UNTIL performs a test, which
> AGAIN does not. An optimizer would handle it properly, as in the "other
> languages," but not all Forths.
>
> It's certainly not a big deal, though. AGAIN is just a convenience, and
> in some circumstances a minor optimization.

Can you specify those circumstances?

I'll accept AGAIN is useful in defining REPEAT because the latter is
used so often, but that's about it.

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

#19708

Ed <invalid@nospam.com> wrote:
> Elizabeth D. Rather wrote:
>> On 2/10/13 3:56 PM, Ed wrote:
>> > ...
>> > "Starting FORTH" (first ed.) talks about creating infinite loops with
>> > BEGIN...0 UNTIL.  AFAIK AGAIN is not referenced anywhere.
>> >
>> > When this topic came up before some folks pointed out other
>> > languages would optimize the equivalent of 0 UNTIL into an AGAIN.
>> > Having a specific construct for infinite loops in these languages
>> > would thus be redundant.
>> >
>> > Some folks say BEGIN... AGAIN is faster that BEGIN...0 UNTIL
>> > but I can't think of a scenario where this would be true.
>>
>> Well, at least in a traditional Forth, UNTIL performs a test, which
>> AGAIN does not. An optimizer would handle it properly, as in the "other
>> languages," but not all Forths.
>>
>> It's certainly not a big deal, though. AGAIN is just a convenience, and
>> in some circumstances a minor optimization.
> 
> Can you specify those circumstances?

They're still the circumstances that I specified.

In any case, AGAIN is easier to read than 0 UNTIL so it's worth having
even if AGAIN is defined

: again ( C: dest -- )   0 postpone literal  postpone until ;
  immediate

If you don't use multi-tasking, AGAIN is not so obviously useful, but
classic Forth had (still has) a lot of co-operating small tasks, all
running as infinite loops.

Andrew.

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

#19667

On Feb 11, 1:56 am, "Ed" <inva...@nospam.com> wrote:
> Alex Wegel wrote:
> > ...
> > But you *do* agree that infinite loops exist (even in forth), and that
> > they differ from the other constructs having been mentioned?
> ...
> > My original point wasn't so much about AGAIN, more about recognizing the
> > infinite loop as a basic looping construct in general.
>
> None of the CS texts I've read mention infinite loops as a fundamental
> construct.  When they're discussed they're described in terms of the
> classic loops, which in Forth would be BEGIN... 0 UNTIL or BEGIN...
> 1 WHILE...REPEAT.
>
> "Starting FORTH" (first ed.) talks about creating infinite loops with
> BEGIN...0 UNTIL.  AFAIK AGAIN is not referenced anywhere.
>
> When this topic came up before some folks pointed out other
> languages would optimize the equivalent of 0 UNTIL into an AGAIN.
> Having a specific construct for infinite loops in these languages
> would thus be redundant.
>
> Some folks say BEGIN... AGAIN is faster that BEGIN...0 UNTIL
> but I can't think of a scenario where this would be true.

It would be faster in my system ;-)

My system doesn't compile a conditional branch. It compiles an
unconditional branch.

The definition of AGAIN in my system is:

: AGAIN ( addr -- )
    COMPILE BRANCH , ; IMMEDIATE

Addresses in my system are absolute, not relative.

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

#19688

Mark Wills wrote:
> On Feb 11, 1:56 am, "Ed" <inva...@nospam.com> wrote:
> > Alex Wegel wrote:
> > > ...
> > > But you *do* agree that infinite loops exist (even in forth), and that
> > > they differ from the other constructs having been mentioned?
> > ...
> > > My original point wasn't so much about AGAIN, more about recognizing the
> > > infinite loop as a basic looping construct in general.
> >
> > None of the CS texts I've read mention infinite loops as a fundamental
> > construct. When they're discussed they're described in terms of the
> > classic loops, which in Forth would be BEGIN... 0 UNTIL or BEGIN...
> > 1 WHILE...REPEAT.
> >
> > "Starting FORTH" (first ed.) talks about creating infinite loops with
> > BEGIN...0 UNTIL. AFAIK AGAIN is not referenced anywhere.
> >
> > When this topic came up before some folks pointed out other
> > languages would optimize the equivalent of 0 UNTIL into an AGAIN.
> > Having a specific construct for infinite loops in these languages
> > would thus be redundant.
> >
> > Some folks say BEGIN... AGAIN is faster that BEGIN...0 UNTIL
> > but I can't think of a scenario where this would be true.
>
> It would be faster in my system ;-)
>
> My system doesn't compile a conditional branch. It compiles an
> unconditional branch.
>
> The definition of AGAIN in my system is:
>
> : AGAIN ( addr -- )
>     COMPILE BRANCH , ; IMMEDIATE
>
> Addresses in my system are absolute, not relative.

So does mine.  But that wasn't the challenge.  Demonstrate - if you can -
that using BEGIN.. AGAIN in an application produces a speed improvement
over the equivalent BEGIN..0 UNTIL.

My contention is that it won't and can't because the fastest scenario is
an empty infinite loop - which also happens to be the ultimate time waster.
The more useful things you do in the loop, the less time you waste, and
the less impact AGAIN or 0 UNTIL will have.

The notion that BEGIN..AGAIN is faster than BEGIN..0 UNTIL is, as far
as I can determine, a wonderful delusion.

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

#19689

On 2/12/13 3:34 PM, Ed wrote:
> Mark Wills wrote:
>> On Feb 11, 1:56 am, "Ed" <inva...@nospam.com> wrote:
>>> Alex Wegel wrote:
>>>> ...
>>>> But you *do* agree that infinite loops exist (even in forth), and that
>>>> they differ from the other constructs having been mentioned?
>>> ...
>>>> My original point wasn't so much about AGAIN, more about recognizing the
>>>> infinite loop as a basic looping construct in general.
>>>
>>> None of the CS texts I've read mention infinite loops as a fundamental
>>> construct. When they're discussed they're described in terms of the
>>> classic loops, which in Forth would be BEGIN... 0 UNTIL or BEGIN...
>>> 1 WHILE...REPEAT.
>>>
>>> "Starting FORTH" (first ed.) talks about creating infinite loops with
>>> BEGIN...0 UNTIL. AFAIK AGAIN is not referenced anywhere.
>>>
>>> When this topic came up before some folks pointed out other
>>> languages would optimize the equivalent of 0 UNTIL into an AGAIN.
>>> Having a specific construct for infinite loops in these languages
>>> would thus be redundant.
>>>
>>> Some folks say BEGIN... AGAIN is faster that BEGIN...0 UNTIL
>>> but I can't think of a scenario where this would be true.
>>
>> It would be faster in my system ;-)
>>
>> My system doesn't compile a conditional branch. It compiles an
>> unconditional branch.
>>
>> The definition of AGAIN in my system is:
>>
>> : AGAIN ( addr -- )
>>      COMPILE BRANCH , ; IMMEDIATE
>>
>> Addresses in my system are absolute, not relative.
>
> So does mine.  But that wasn't the challenge.  Demonstrate - if you can -
> that using BEGIN.. AGAIN in an application produces a speed improvement
> over the equivalent BEGIN..0 UNTIL.
>
> My contention is that it won't and can't because the fastest scenario is
> an empty infinite loop - which also happens to be the ultimate time waster.
> The more useful things you do in the loop, the less time you waste, and
> the less impact AGAIN or 0 UNTIL will have.
>
> The notion that BEGIN..AGAIN is faster than BEGIN..0 UNTIL is, as far
> as I can determine, a wonderful delusion.

Well, but you didn't stipulate a *significant* speed improvement. Mark 
indisputably demonstrated *a* speed improvement by removing an 
unnecessary test.

Surely we can agree that AGAIN provides a very minor speed improvement 
on some systems, and a notational improvement, and leave it to folks to 
make individual value judgements about those things. This is far from 
the only such issue in Forth. There's 1+, 2* and 2/, a whole list of 
these little things. Some folks' aesthetics are offended by adding an 
unnecessary word to the system, others by executing an unnecessary 
instruction.

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]

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web