Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #44558 > unrolled thread
| Started by | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| First post | 2016-01-04 14:50 -0800 |
| Last post | 2016-01-08 03:04 -0800 |
| Articles | 20 on this page of 100 — 18 participants |
Back to article view | Back to comp.lang.forth
BEGIN WHILE UNTIL THEN Julian Fondren <julian.fondren@gmail.com> - 2016-01-04 14:50 -0800
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-05 11:24 +1100
Re: BEGIN WHILE UNTIL THEN Julian Fondren <julian.fondren@gmail.com> - 2016-01-04 16:47 -0800
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-05 12:17 +1100
Re: BEGIN WHILE UNTIL THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-05 10:51 +0000
Re: BEGIN WHILE UNTIL THEN stephen@mpeforth.com (Stephen Pelc) - 2016-01-05 15:06 +0000
Re: BEGIN WHILE UNTIL THEN Chris Curl <ccurl609@gmail.com> - 2016-01-04 17:25 -0800
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-05 13:06 +1100
Re: BEGIN WHILE UNTIL THEN Chris Curl <ccurl609@gmail.com> - 2016-01-04 21:42 -0800
Re: BEGIN WHILE UNTIL THEN rickman <gnuarm@gmail.com> - 2016-01-05 01:48 -0500
Re: BEGIN WHILE UNTIL THEN Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-05 11:15 +0000
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-06 14:35 +1100
Re: BEGIN WHILE UNTIL THEN Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-05 02:04 +0000
Re: BEGIN WHILE UNTIL THEN Julian Fondren <julian.fondren@gmail.com> - 2016-01-04 18:37 -0800
Re: BEGIN WHILE UNTIL THEN hughaguilar96@gmail.com - 2016-01-04 19:17 -0800
Re: BEGIN WHILE UNTIL THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-05 11:10 +0000
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-06 15:02 +1100
Re: BEGIN WHILE UNTIL THEN november.nihal@gmail.com - 2016-01-05 08:03 -0800
Re: BEGIN WHILE UNTIL THEN november.nihal@gmail.com - 2016-01-05 08:07 -0800
Re: BEGIN WHILE UNTIL THEN november.nihal@gmail.com - 2016-01-05 08:18 -0800
Re: BEGIN WHILE UNTIL THEN november.nihal@gmail.com - 2016-01-05 08:21 -0800
Re: BEGIN WHILE UNTIL THEN Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-07 05:13 -0500
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-08 12:36 +1100
Re: BEGIN WHILE UNTIL THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-08 10:32 +0000
Re: BEGIN WHILE UNTIL THEN Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-08 02:55 -0800
Re: BEGIN WHILE UNTIL THEN Coos Haak <chforth@hccnet.nl> - 2016-01-08 13:57 +0100
Re: BEGIN WHILE UNTIL THEN Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-08 06:55 -0800
Re: BEGIN WHILE UNTIL THEN hughaguilar96@gmail.com - 2016-01-08 15:06 -0800
Re: BEGIN WHILE UNTIL THEN Chris Curl <ccurl609@gmail.com> - 2016-01-08 16:59 -0800
Re: BEGIN WHILE UNTIL THEN "Elizabeth D. Rather" <erather@forth.com> - 2016-01-08 16:15 -1000
Re: BEGIN WHILE UNTIL THEN Chris Curl <ccurl609@gmail.com> - 2016-01-08 22:23 -0800
Re: BEGIN WHILE UNTIL THEN "Elizabeth D. Rather" <erather@forth.com> - 2016-01-08 21:12 -1000
Re: BEGIN WHILE UNTIL THEN Chris Curl <ccurl609@gmail.com> - 2016-01-09 08:04 -0800
Re: BEGIN WHILE UNTIL THEN "Elizabeth D. Rather" <erather@forth.com> - 2016-01-09 09:16 -1000
Re: BEGIN WHILE UNTIL THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-10 15:31 +0000
Re: BEGIN WHILE UNTIL THEN Chris Curl <ccurl609@gmail.com> - 2016-01-10 08:11 -0800
Re: BEGIN WHILE UNTIL THEN "Elizabeth D. Rather" <erather@forth.com> - 2016-01-10 09:42 -1000
Re: BEGIN WHILE UNTIL THEN Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-01-11 13:02 +0000
Re: BEGIN WHILE UNTIL THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-13 16:20 +0000
Re: BEGIN WHILE UNTIL THEN hughaguilar96@gmail.com - 2016-01-10 14:10 -0800
Re: BEGIN WHILE UNTIL THEN hughaguilar96@gmail.com - 2016-01-11 18:38 -0800
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-14 08:47 +1100
Re: BEGIN WHILE UNTIL THEN Chris Curl <ccurl609@gmail.com> - 2016-01-13 17:24 -0800
Re: BEGIN WHILE UNTIL THEN hughaguilar96@gmail.com - 2016-01-13 19:25 -0800
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-14 22:09 +1100
Re: BEGIN WHILE UNTIL THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-14 16:21 +0000
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-16 11:34 +1100
Re: BEGIN WHILE UNTIL THEN Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-16 03:43 +0100
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-19 18:01 +1100
Re: BEGIN WHILE UNTIL THEN Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-19 23:07 +0100
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-21 14:29 +1100
Re: BEGIN WHILE UNTIL THEN Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-21 22:25 +0100
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-24 13:28 +1100
Re: BEGIN WHILE UNTIL THEN Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-25 01:31 +0100
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-25 21:45 +1100
Re: BEGIN WHILE UNTIL THEN Chris Curl <ccurl609@gmail.com> - 2016-01-25 10:24 -0800
Re: BEGIN WHILE UNTIL THEN Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-25 20:41 +0100
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-28 20:39 +1100
Re: BEGIN WHILE UNTIL THEN Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-28 16:05 +0100
Re: BEGIN WHILE UNTIL THEN Chris Curl <ccurl609@gmail.com> - 2016-01-21 20:52 -0800
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-24 13:16 +1100
Re: BEGIN WHILE UNTIL THEN Chris Curl <ccurl609@gmail.com> - 2016-01-14 08:46 -0800
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-16 11:34 +1100
Re: BEGIN WHILE UNTIL THEN Chris Curl <ccurl609@gmail.com> - 2016-01-15 20:53 -0800
Re: BEGIN WHILE UNTIL THEN hughaguilar96@gmail.com - 2016-01-13 19:31 -0800
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-11 09:29 +1100
Re: BEGIN WHILE UNTIL THEN Chris Curl <ccurl609@gmail.com> - 2016-01-10 21:18 -0800
Re: BEGIN WHILE UNTIL THEN Paul Rubin <no.email@nospam.invalid> - 2016-01-10 21:29 -0800
Re: BEGIN WHILE UNTIL THEN "Elizabeth D. Rather" <erather@forth.com> - 2016-01-10 20:37 -1000
Re: BEGIN WHILE UNTIL THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-11 09:05 +0000
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-12 12:26 +1100
Re: BEGIN WHILE UNTIL THEN hughaguilar96@gmail.com - 2016-01-10 14:18 -0800
Re: BEGIN WHILE UNTIL THEN Raimond Dragomir <raimond.dragomir@gmail.com> - 2016-01-08 23:31 -0800
Re: BEGIN WHILE UNTIL THEN Chris Curl <ccurl609@gmail.com> - 2016-01-09 08:09 -0800
Re: BEGIN WHILE UNTIL THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-09 05:31 -0600
Re: BEGIN WHILE UNTIL THEN Andrew Haley <andrew29@littlepinkcloud.invalid> - 2016-01-09 07:52 -0600
Re: BEGIN WHILE UNTIL THEN Ron Aaron <rambamist@gmail.com> - 2016-01-09 18:22 +0200
Re: BEGIN WHILE UNTIL THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-09 16:29 +0000
Re: BEGIN WHILE UNTIL THEN stephen@mpeforth.com (Stephen Pelc) - 2016-01-08 11:23 +0000
Re: BEGIN WHILE UNTIL THEN hughaguilar96@gmail.com - 2016-01-10 20:17 -0800
Re: BEGIN WHILE UNTIL THEN stephen@mpeforth.com (Stephen Pelc) - 2016-01-11 11:56 +0000
Re: BEGIN WHILE UNTIL THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-11 11:59 +0000
generalized CASE (was: BEGIN WHILE UNTIL THEN) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-11 12:30 +0000
Re: generalized CASE (was: BEGIN WHILE UNTIL THEN) hughaguilar96@gmail.com - 2016-01-11 13:52 -0800
Re: generalized CASE Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-11 22:00 +0000
Re: generalized CASE Coos Haak <chforth@hccnet.nl> - 2016-01-12 01:50 +0100
Re: BEGIN WHILE UNTIL THEN hughaguilar96@gmail.com - 2016-01-11 14:16 -0800
Re: BEGIN WHILE UNTIL THEN Chris Curl <ccurl609@gmail.com> - 2016-01-11 16:17 -0800
Re: BEGIN WHILE UNTIL THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-12 13:07 +0000
Re: BEGIN WHILE UNTIL THEN Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-01-12 20:48 +0000
Re: BEGIN WHILE UNTIL THEN hughaguilar96@gmail.com - 2016-01-12 14:16 -0800
Re: BEGIN WHILE UNTIL THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-08 16:21 +0000
Re: BEGIN WHILE UNTIL THEN stephen@mpeforth.com (Stephen Pelc) - 2016-01-08 20:12 +0000
Re: BEGIN WHILE UNTIL THEN anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-01-09 18:19 +0000
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-11 09:34 +1100
Re: BEGIN WHILE UNTIL THEN Bernd Paysan <bernd.paysan@gmx.de> - 2016-01-08 21:13 +0100
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-09 23:46 +1100
Re: BEGIN WHILE UNTIL THEN Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> - 2016-01-08 10:11 -0500
Re: BEGIN WHILE UNTIL THEN "HAA" <someone@microsoft.com> - 2016-01-11 08:38 +1100
Re: BEGIN WHILE UNTIL THEN november.nihal@gmail.com - 2016-01-08 03:04 -0800
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | november.nihal@gmail.com |
|---|---|
| Date | 2016-01-05 08:21 -0800 |
| Message-ID | <5b11bef2-73ce-4468-9de7-ef2c7d8b0e0b@googlegroups.com> |
| In reply to | #44586 |
On Tuesday, 5 January 2016 16:07:15 UTC, novembe...@gmail.com wrote: > Sorry about the spacing I didn't realise that tabbing would post it. > Its untested, but would this be the general gist of translation I wanted to ask ? > > NN Reposting : : update-links3 begin @ dup if abort then 2dup = until ; : update-links2 ['] update-links3 catch if drop nip else 2drop r> @ swap ! exit then ; : update-links1 begin dup @ dup while r@ update-links2 repeat ; : update-links ( super link -- ) r> update-links1 r> drop 2drop ;
[toc] | [prev] | [next] | [standalone]
| From | Rod Pemberton <NoHaveNotOne@bcczxcfre.cmm> |
|---|---|
| Date | 2016-01-07 05:13 -0500 |
| Message-ID | <20160107051310.67828226@_> |
| In reply to | #44558 |
On Mon, 4 Jan 2016 14:50:25 -0800 (PST)
Julian Fondren <julian.fondren@gmail.com> wrote:
> The following code is from SwoopPortable.f
>
> : UPDATE-LINKS ( super link -- ) >R
> BEGIN
> DUP @ DUP WHILE \ prev cur
> R@ BEGIN \ prev cur sup
> @ DUP WHILE \ prev cur sup'
> 2DUP = UNTIL
> 2DROP R> @ SWAP ! EXIT
> THEN DROP NIP
> REPEAT R> DROP 2DROP ;
>
> Can someone rewrite this with normal control-flow?
>
Reformatting, ...
: UPDATE-LINKS ( super link -- )
>R
BEGIN
DUP @ DUP
WHILE \ prev cur
R@
BEGIN \ prev cur sup
@ DUP
WHILE \ prev cur sup'
2DUP =
UNTIL
2DROP R> @ SWAP !
EXIT
THEN
DROP NIP
REPEAT
R> DROP 2DROP
;
I'm not sure I understand fully how this
BEGIN-WHILE-UNTIL-THEN thing works ...
My guess is that a false condition (NULL pointer
terminating a linked-list) at the WHILE in the inner
loop continues at the THEN's "DROP NIP" for end-of-list.
Otherwise, if not end-of-list, then BEGIN-WHILE-UNTIL
cycles until a pointer match is found. When found,
the code after the UNTIL is executed for the true match.
If so, then the inner BEGIN-WHILE-UNTIL-THEN loop
is really a BEGIN-UNTIL followed by an IF-ELSE-THEN,
where the BEGIN-UNTIL is checking for two conditions
to exit. Since the BEGIN-UNTIL now exits for two
conditions, you must determine which condition caused
it to exit, afterwards. E.g., the BEGIN-WHILE-UNTIL-THEN
is something to the effect of this BEGIN-UNTIL with
two exit conditions, which is not tested, and is
possibly incorrect for the sample code above ...
BEGIN
@ 2DUP = OVER 0= OR \ OR two exit conditions
UNTIL
IF
DROP ... EXIT \ DROP one since IF took one ...
ELSE
DROP NIP
THEN
Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-01-08 12:36 +1100 |
| Message-ID | <n6n3q1$u8j$1@gioia.aioe.org> |
| In reply to | #44658 |
Rod Pemberton wrote:
> ...
> Since the BEGIN-UNTIL now exits for two
> conditions, you must determine which condition caused
> it to exit, afterwards.
> ...
This is the problem ANS WHILE was designed to solve. It lets you exit the
loop at different points avoiding the need to test (again) which condition
caused the exit e.g.
BEGIN test1 WHILE test2 WHILE ... REPEAT exit2 ELSE exit1 THEN
BEGIN test1 WHILE test2 UNTIL exit2 ELSE exit1 THEN
Other variations:
BEGIN test1 WHILE test2 WHILE ... REPEAT exit2 THEN exit1
BEGIN test1 WHILE test2 WHILE ... REPEAT THEN exit1/exit2
The topic is discussed by Brodie/Moore in 'Thinking FORTH' Chapter 8 ...
"The value is that you get simpler programs. And it costs nothing."
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-08 10:32 +0000 |
| Message-ID | <2016Jan8.113226@mips.complang.tuwien.ac.at> |
| In reply to | #44671 |
"HAA" <someone@microsoft.com> writes:
>This is the problem ANS WHILE was designed to solve. It lets you exit the
>loop at different points avoiding the need to test (again) which condition
>caused the exit e.g.
>
> BEGIN test1 WHILE test2 WHILE ... REPEAT exit2 ELSE exit1 THEN
>
> BEGIN test1 WHILE test2 UNTIL exit2 ELSE exit1 THEN
>
>Other variations:
>
> BEGIN test1 WHILE test2 WHILE ... REPEAT exit2 THEN exit1
>
> BEGIN test1 WHILE test2 WHILE ... REPEAT THEN exit1/exit2
>
>The topic is discussed by Brodie/Moore in 'Thinking FORTH' Chapter 8 ...
>
>"The value is that you get simpler programs. And it costs nothing."
There is a mind load cost in the first three examples: the exit
fragments are not right where the corresponding conditions are, but
you have to count the WHILEs and THENs and ELSEs, and match them up.
That's why I prefer things like:
begin
test1 if exit1 EXIT then
test2 if exit2 EXIT then
...
again
The disadvantage here is that the word ends after the loop, so if you
have a common thing to do afterwards, you have to wrap another word
around this one, or put the common code in a word, and call it before
every EXIT.
- 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]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2016-01-08 02:55 -0800 |
| Message-ID | <d9ce8bc7-635a-4596-94f6-a29173edf95d@googlegroups.com> |
| In reply to | #44683 |
> That's why I prefer things like: > > begin > test1 if exit1 EXIT then > test2 if exit2 EXIT then > ... > again > > The disadvantage here is that the word ends after the loop, so if you > have a common thing to do afterwards, you have to wrap another word > around this one, or put the common code in a word, and call it before > every EXIT. > > - 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/ Or implement a BREAK word for BEGIN...AGAIN and BEGIN...UNTIL loops: begin test1 if thing1 break then test2 if thing2 break then ... again This way we can get rid of BEGIN...WHILE...REPEAT loops entirely.
[toc] | [prev] | [next] | [standalone]
| From | Coos Haak <chforth@hccnet.nl> |
|---|---|
| Date | 2016-01-08 13:57 +0100 |
| Message-ID | <1sd7kgo4ggg3p.k6o6itng6e2k$.dlg@40tude.net> |
| In reply to | #44685 |
Op Fri, 8 Jan 2016 02:55:19 -0800 (PST) schreef Raimond Dragomir: >> That's why I prefer things like: >> >> begin >> test1 if exit1 EXIT then >> test2 if exit2 EXIT then >> ... >> again >> >> The disadvantage here is that the word ends after the loop, so if you >> have a common thing to do afterwards, you have to wrap another word >> around this one, or put the common code in a word, and call it before >> every EXIT. >> >> - 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/ > > Or implement a BREAK word for BEGIN...AGAIN and BEGIN...UNTIL loops: > > begin > test1 if thing1 break then > test2 if thing2 break then > ... > again If BREAK does EXIT why not write EXIT ? If BREAK jumps behind AGAIN why complicate the compiler? > > This way we can get rid of BEGIN...WHILE...REPEAT loops entirely. It checks the condition at the beginning. BEGIN...UNTIL check a the end. Both have merit. groet Coos
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2016-01-08 06:55 -0800 |
| Message-ID | <70feb98c-9be3-4821-9bf8-76d8066287cf@googlegroups.com> |
| In reply to | #44688 |
> > begin > > test1 if thing1 break then > > test2 if thing2 break then > > ... > > again > > If BREAK does EXIT why not write EXIT ? It breaks the loop. > If BREAK jumps behind AGAIN why complicate the compiler? Why not? Why not another word which is missing: CONTINUE Forth doesn't have BREAK and CONTINUE which are very clear and simpel, but has coding horrors like BEGIN WHILE UNTIL THEN and such. So, why not complicate the compiler a bit? > > This way we can get rid of BEGIN...WHILE...REPEAT loops entirely. > > It checks the condition at the beginning. > BEGIN...UNTIL check a the end. Both have merit. > > groet Coos Of course WHILE has its merit, if it's not abused. But having a BREAK you can have multiple exit points with very clear coding. And without being force to use EXIT and make additional new definitions with silly names just because the languages doesn't have proper tools to help you coding even simple things.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-08 15:06 -0800 |
| Message-ID | <70ae0d8f-1adf-4041-9f41-d58881e1b322@googlegroups.com> |
| In reply to | #44691 |
On Friday, January 8, 2016 at 7:55:31 AM UTC-7, Raimond Dragomir wrote: > > > begin > > > test1 if thing1 break then > > > test2 if thing2 break then > > > ... > > > again > > > > If BREAK does EXIT why not write EXIT ? > > It breaks the loop. > > > If BREAK jumps behind AGAIN why complicate the compiler? > > Why not? > Why not another word which is missing: CONTINUE > > Forth doesn't have BREAK and CONTINUE which are very clear and simpel, > but has coding horrors like BEGIN WHILE UNTIL THEN and such. > > So, why not complicate the compiler a bit? > > > > > This way we can get rid of BEGIN...WHILE...REPEAT loops entirely. > > > > It checks the condition at the beginning. > > BEGIN...UNTIL check a the end. Both have merit. > > > > groet Coos > > Of course WHILE has its merit, if it's not abused. > But having a BREAK you can have multiple exit points with very > clear coding. And without being force to use EXIT and make > additional new definitions with silly names just because > the languages doesn't have proper tools to help you coding > even simple things. That seems reasonable to me. I think you're going in the right direction with your language design.
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-08 16:59 -0800 |
| Message-ID | <7eebea9d-6688-47c2-ba12-a9d070260881@googlegroups.com> |
| In reply to | #44691 |
On Friday, January 8, 2016 at 9:55:31 AM UTC-5, Raimond Dragomir wrote: > > > begin > > > test1 if thing1 break then > > > test2 if thing2 break then > > > ... > > > again > > > > If BREAK does EXIT why not write EXIT ? > > It breaks the loop. > > > If BREAK jumps behind AGAIN why complicate the compiler? > > Why not? > Why not another word which is missing: CONTINUE > > Forth doesn't have BREAK and CONTINUE which are very clear and simpel, > but has coding horrors like BEGIN WHILE UNTIL THEN and such. > > So, why not complicate the compiler a bit? > > > > > This way we can get rid of BEGIN...WHILE...REPEAT loops entirely. > > > > It checks the condition at the beginning. > > BEGIN...UNTIL check a the end. Both have merit. > > > > groet Coos > > Of course WHILE has its merit, if it's not abused. > But having a BREAK you can have multiple exit points with very > clear coding. And without being force to use EXIT and make > additional new definitions with silly names just because > the languages doesn't have proper tools to help you coding > even simple things. For me, the "why not?" is that I don't have a need for it, and I don't feel like dealing with the complication of implementing it. Since there could potentially be very many "break"s, you will need to keep track of them all somewhere and then resolve them all at the right time. The seems like more work than is necessary. I would just write it so that the inner logic is a separate word that is referred to in the loop. That also has the advantage of making that logic available to other words should the need present itself. And off the record, I suspect that the whole "using THEN in weird places where there is no corresponding IF" just so happened to work like that when they were considering putting the "standard" together, that they decided to include it in the standard because it seemed pretty slick. I, for one doubt very much that I would ever structure my code in such a way as to need (or even want) such a construct. As such, my implementation will never be "compliant" because it won't be supporting that construct.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-01-08 16:15 -1000 |
| Message-ID | <QZCdnZGO7fqj8A3LnZ2dnUU7-LednZ2d@supernews.com> |
| In reply to | #44699 |
On 1/8/16 2:59 PM, Chris Curl wrote: > On Friday, January 8, 2016 at 9:55:31 AM UTC-5, Raimond Dragomir wrote: >>>> begin >>>> test1 if thing1 break then >>>> test2 if thing2 break then >>>> ... >>>> again >>> >>> If BREAK does EXIT why not write EXIT ? >> >> It breaks the loop. >> >>> If BREAK jumps behind AGAIN why complicate the compiler? >> >> Why not? >> Why not another word which is missing: CONTINUE >> >> Forth doesn't have BREAK and CONTINUE which are very clear and simpel, >> but has coding horrors like BEGIN WHILE UNTIL THEN and such. >> >> So, why not complicate the compiler a bit? >> >> >>>> This way we can get rid of BEGIN...WHILE...REPEAT loops entirely. >>> >>> It checks the condition at the beginning. >>> BEGIN...UNTIL check a the end. Both have merit. >>> >>> groet Coos >> >> Of course WHILE has its merit, if it's not abused. >> But having a BREAK you can have multiple exit points with very >> clear coding. And without being force to use EXIT and make >> additional new definitions with silly names just because >> the languages doesn't have proper tools to help you coding >> even simple things. Multiple exit points in a Forth definition? Should be incredibly rare, as it tends to shout, "Poor Factoring!!!" > For me, the "why not?" is that I don't have a need for it, and > I don't feel like dealing with the complication of implementing it. > Since there could potentially be very many "break"s, you will need > to keep track of them all somewhere and then resolve them all at the > right time. The seems like more work than is necessary. I would just > write it so that the inner logic is a separate word that is referred > to in the loop. That also has the advantage of making that logic available > to other words should the need present itself. Chris, you really have the right idea. > And off the record, I suspect that the whole "using THEN in weird places > where there is no corresponding IF" just so happened to work like that > when they were considering putting the "standard" together, that they > decided to include it in the standard because it seemed pretty slick. > I, for one doubt very much that I would ever structure my code in such > a way as to need (or even want) such a construct. As such, my implementation > will never be "compliant" because it won't be supporting that construct. There is *no* complication of implementing this behavior. In fact, the simplest implementations of THEN is just: : THEN ( orig -- ) HERE SWAP ! ; IMMEDIATE (in an integrated code/data implementation) That is, THEN simply takes an 'orig' (address of a place holder) and patches it with the next available address in your code space, which becomes the destination of some kind of branch (it doesn't compile anything in the destination address). THEN doesn't care where the 'orig' came from. In fact, in many compilers, the compile-time THEN is called by words such as UNTIL and REPEAT that need to satisfy an 'orig' and additionally compile a branch. So, it's not anything that was added, it's just a side effect of simple implementation, and has been around long before any standard. Putting it in a standard merely guarantees that implementations will honor this tradition. 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]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-08 22:23 -0800 |
| Message-ID | <f22796c6-fe3b-4719-bcaa-40971e8183e5@googlegroups.com> |
| In reply to | #44700 |
On Friday, January 8, 2016 at 9:15:28 PM UTC-5, Elizabeth D. Rather wrote: > On 1/8/16 2:59 PM, Chris Curl wrote: > > Multiple exit points in a Forth definition? Should be incredibly rare, > as it tends to shout, "Poor Factoring!!!" > I was responding to a post about breaking out of a loop in any number of points loop and then do some more processing. This is a very common construct in "C", "C++" and "C#". It is simple to return from a definition at multiple points. At least, it is in my implementation. > > ... > > Chris, you really have the right idea. Thanks. > > > And off the record, I suspect that the whole "using THEN in weird places > > where there is no corresponding IF" just so happened to work like that > > when they were considering putting the "standard" together, that they > > decided to include it in the standard because it seemed pretty slick. > > I, for one doubt very much that I would ever structure my code in such > > a way as to need (or even want) such a construct. As such, my implementation > > will never be "compliant" because it won't be supporting that construct. > > There is *no* complication of implementing this behavior. In fact, the > simplest implementations of THEN is just: > > : THEN ( orig -- ) HERE SWAP ! ; IMMEDIATE > For what it's worth, that is exactly how my THEN is defined as well. > (in an integrated code/data implementation) That is, THEN simply takes > an 'orig' (address of a place holder) and patches it with the next > available address in your code space, which becomes the destination of > some kind of branch (it doesn't compile anything in the destination > address). THEN doesn't care where the 'orig' came from. In fact, in many > compilers, the compile-time THEN is called by words such as UNTIL and > REPEAT that need to satisfy an 'orig' and additionally compile a branch. > So, it's not anything that was added, it's just a side effect of simple > implementation, and has been around long before any standard. Putting it > in a standard merely guarantees that implementations will honor this > tradition. > So my suspicion was right. The behavior simply to resolve a single forward, and since those other constructs set things up the same way, it works. As convenient as it is, it is my opinion that it is not at all intuitive. And I am far from a newbie at this .... I have been a professional software developer for over 30 years now.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-01-08 21:12 -1000 |
| Message-ID | <L8adnWOmEutqLw3LnZ2dnUU7-X-dnZ2d@supernews.com> |
| In reply to | #44716 |
On 1/8/16 8:23 PM, Chris Curl wrote: > On Friday, January 8, 2016 at 9:15:28 PM UTC-5, Elizabeth D. Rather wrote: >> On 1/8/16 2:59 PM, Chris Curl wrote: >> >> Multiple exit points in a Forth definition? Should be incredibly rare, >> as it tends to shout, "Poor Factoring!!!" >> > I was responding to a post about breaking out of a loop in any number of > points loop and then do some more processing. This is a very common construct > in "C", "C++" and "C#". > > It is simple to return from a definition at multiple points. At least, > it is in my implementation. Yes, but the style in C etc. is subroutines measured in pages. The style in Forth is definitions 2 or 3 lines long. They don't need such tortured logic. >>> ... >> >> Chris, you really have the right idea. > > Thanks. > >> >>> And off the record, I suspect that the whole "using THEN in weird places >>> where there is no corresponding IF" just so happened to work like that >>> when they were considering putting the "standard" together, that they >>> decided to include it in the standard because it seemed pretty slick. >>> I, for one doubt very much that I would ever structure my code in such >>> a way as to need (or even want) such a construct. As such, my implementation >>> will never be "compliant" because it won't be supporting that construct. >> >> There is *no* complication of implementing this behavior. In fact, the >> simplest implementations of THEN is just: >> >> : THEN ( orig -- ) HERE SWAP ! ; IMMEDIATE >> > > For what it's worth, that is exactly how my THEN is defined as well. Yay, Chris! So, why did you think it took more complexity to let THEN satisfy more things? >> (in an integrated code/data implementation) That is, THEN simply takes >> an 'orig' (address of a place holder) and patches it with the next >> available address in your code space, which becomes the destination of >> some kind of branch (it doesn't compile anything in the destination >> address). THEN doesn't care where the 'orig' came from. In fact, in many >> compilers, the compile-time THEN is called by words such as UNTIL and >> REPEAT that need to satisfy an 'orig' and additionally compile a branch. >> So, it's not anything that was added, it's just a side effect of simple >> implementation, and has been around long before any standard. Putting it >> in a standard merely guarantees that implementations will honor this >> tradition. >> > So my suspicion was right. The behavior simply to resolve a single > forward, and since those other constructs set things up the same way, > it works. As convenient as it is, it is my opinion that it is not at > all intuitive. And I am far from a newbie at this .... I have been a > professional software developer for over 30 years now. It's not something you're used to if you have learned to consider structures as discrete, policed entities. If your orientation is simply to consider words and what they do, it's perfectly simple and intuitive. 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]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-09 08:04 -0800 |
| Message-ID | <466e4fc1-66f3-4842-8350-55fa9c80fcdd@googlegroups.com> |
| In reply to | #44717 |
On Saturday, January 9, 2016 at 2:12:57 AM UTC-5, Elizabeth D. Rather wrote:
> On 1/8/16 8:23 PM, Chris Curl wrote:
> > On Friday, January 8, 2016 at 9:15:28 PM UTC-5, Elizabeth D. Rather wrote:
> >> On 1/8/16 2:59 PM, Chris Curl wrote:
> >>
> >> Multiple exit points in a Forth definition? Should be incredibly rare,
> >> as it tends to shout, "Poor Factoring!!!"
> >>
> > I was responding to a post about breaking out of a loop in any number of
> > points loop and then do some more processing. This is a very common construct
> > in "C", "C++" and "C#".
> >
> > It is simple to return from a definition at multiple points. At least,
> > it is in my implementation.
>
> Yes, but the style in C etc. is subroutines measured in pages. The style
> in Forth is definitions 2 or 3 lines long. They don't need such tortured
> logic.
>
> >>> ...
> >>
> >> Chris, you really have the right idea.
> >
> > Thanks.
> >
> >>
> >>> And off the record, I suspect that the whole "using THEN in weird places
> >>> where there is no corresponding IF" just so happened to work like that
> >>> when they were considering putting the "standard" together, that they
> >>> decided to include it in the standard because it seemed pretty slick.
> >>> I, for one doubt very much that I would ever structure my code in such
> >>> a way as to need (or even want) such a construct. As such, my implementation
> >>> will never be "compliant" because it won't be supporting that construct.
> >>
> >> There is *no* complication of implementing this behavior. In fact, the
> >> simplest implementations of THEN is just:
> >>
> >> : THEN ( orig -- ) HERE SWAP ! ; IMMEDIATE
> >>
> >
> > For what it's worth, that is exactly how my THEN is defined as well.
>
> Yay, Chris! So, why did you think it took more complexity to let THEN
> satisfy more things?
>
>
> >> (in an integrated code/data implementation) That is, THEN simply takes
> >> an 'orig' (address of a place holder) and patches it with the next
> >> available address in your code space, which becomes the destination of
> >> some kind of branch (it doesn't compile anything in the destination
> >> address). THEN doesn't care where the 'orig' came from. In fact, in many
> >> compilers, the compile-time THEN is called by words such as UNTIL and
> >> REPEAT that need to satisfy an 'orig' and additionally compile a branch.
> >> So, it's not anything that was added, it's just a side effect of simple
> >> implementation, and has been around long before any standard. Putting it
> >> in a standard merely guarantees that implementations will honor this
> >> tradition.
> >>
> > So my suspicion was right. The behavior simply to resolve a single
> > forward, and since those other constructs set things up the same way,
> > it works. As convenient as it is, it is my opinion that it is not at
> > all intuitive. And I am far from a newbie at this .... I have been a
> > professional software developer for over 30 years now.
>
> It's not something you're used to if you have learned to consider
> structures as discrete, policed entities. If your orientation is simply
> to consider words and what they do, it's perfectly simple and intuitive.
>
> Cheers,
> Elizabeth
>
> --
> ==================================================
Elizabeth, I was and am talking about constructs like this:
: some-loop
begin do-whatever
yyy if break then \ this then is simple!
zzz if break then
ccc if break then
\ any number of other conditions with "break"
again
then do-more-whatever \ this then ... not so much
;
I am talking about the then (or whatever other word you choose to
call it) after again that that needs to resolve ALL the breaks.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-01-09 09:16 -1000 |
| Message-ID | <0dqdnRdSHaEcwQzLnZ2dnUU7-bOdnZ2d@supernews.com> |
| In reply to | #44722 |
On 1/9/16 6:04 AM, Chris Curl wrote:
> On Saturday, January 9, 2016 at 2:12:57 AM UTC-5, Elizabeth D. Rather wrote:
>> On 1/8/16 8:23 PM, Chris Curl wrote:
>>> On Friday, January 8, 2016 at 9:15:28 PM UTC-5, Elizabeth D. Rather wrote:
>>>> On 1/8/16 2:59 PM, Chris Curl wrote:
>>>>
>>>> Multiple exit points in a Forth definition? Should be incredibly rare,
>>>> as it tends to shout, "Poor Factoring!!!"
>>>>
>>> I was responding to a post about breaking out of a loop in any number of
>>> points loop and then do some more processing. This is a very common construct
>>> in "C", "C++" and "C#".
>>>
>>> It is simple to return from a definition at multiple points. At least,
>>> it is in my implementation.
>>
>> Yes, but the style in C etc. is subroutines measured in pages. The style
>> in Forth is definitions 2 or 3 lines long. They don't need such tortured
>> logic.
...
>>> So my suspicion was right. The behavior simply to resolve a single
>>> forward, and since those other constructs set things up the same way,
>>> it works. As convenient as it is, it is my opinion that it is not at
>>> all intuitive. And I am far from a newbie at this .... I have been a
>>> professional software developer for over 30 years now.
>>
>> It's not something you're used to if you have learned to consider
>> structures as discrete, policed entities. If your orientation is simply
>> to consider words and what they do, it's perfectly simple and intuitive.
>>
>> Cheers,
>> Elizabeth
>>
>> --
>> ==================================================
> Elizabeth, I was and am talking about constructs like this:
>
> : some-loop
> begin do-whatever
> yyy if break then \ this then is simple!
> zzz if break then
> ccc if break then
> \ any number of other conditions with "break"
> again
> then do-more-whatever \ this then ... not so much
> ;
> I am talking about the then (or whatever other word you choose to
> call it) after again that that needs to resolve ALL the breaks.
That is easy to do providing you use BEGIN ... UNTIL or BEGIN ... WHILE
,,, REPEAT instead of DO, etc., and a CASE structure. Here's an example
from one of the problem sets in Forth Application Techniques:
: ?WAY ( -- )
BEGIN KEY DUP
27 = NOT WHILE \ Quit on ESCape key
DUP 32 OR \ Set lowercase bit
CASE
[CHAR] i OF UP ENDOF
[CHAR] j OF LEFT ENDOF
[CHAR] k OF HOME ENDOF
[CHAR] l OF RIGHT ENDOF
[CHAR] m OF DOWN ENDOF
SWAP DUP 32 127 WITHIN IF EMIT 0 THEN
ENDCASE DROP CR
REPEAT DROP ;
Simple enough. It's just trying to mix the DO structures with the
indefinite loops that causes trouble, and the simple solution is Don't
Do That.
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]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-10 15:31 +0000 |
| Message-ID | <2016Jan10.163141@mips.complang.tuwien.ac.at> |
| In reply to | #44730 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 1/9/16 6:04 AM, Chris Curl wrote:
>> Elizabeth, I was and am talking about constructs like this:
>>
>> : some-loop
>> begin do-whatever
>> yyy if break then \ this then is simple!
>> zzz if break then
>> ccc if break then
>> \ any number of other conditions with "break"
>> again
>> then do-more-whatever \ this then ... not so much
>> ;
>> I am talking about the then (or whatever other word you choose to
>> call it) after again that that needs to resolve ALL the breaks.
>
>That is easy to do providing you use BEGIN ... UNTIL or BEGIN ... WHILE
>,,, REPEAT instead of DO, etc., and a CASE structure. Here's an example
>from one of the problem sets in Forth Application Techniques:
>
>: ?WAY ( -- )
> BEGIN KEY DUP
> 27 = NOT WHILE \ Quit on ESCape key
> DUP 32 OR \ Set lowercase bit
> CASE
> [CHAR] i OF UP ENDOF
> [CHAR] j OF LEFT ENDOF
> [CHAR] k OF HOME ENDOF
> [CHAR] l OF RIGHT ENDOF
> [CHAR] m OF DOWN ENDOF
> SWAP DUP 32 127 WITHIN IF EMIT 0 THEN
> ENDCASE DROP CR
> REPEAT DROP ;
This example exits on just one condition, so it's not an illustration
of a solution to the problem that Chris Curl describes.
>Simple enough. It's just trying to mix the DO structures with the
>indefinite loops that causes trouble, and the simple solution is Don't
>Do That.
Not sure who is trying to do that. As for using WHILE to exit a DO
loop, the only differences from using it to exit a BEGIN loop is that
you have to use UNLOOP on the exiting branch, that you must use THEN
in all cases (while in a BEGIN loop one THEN is integrated into
REPEAT), and it's non-standard. My guess is that Chris Curl finds
both variants disgusting, and people who like
BEGIN ... WHILE ... UNTIL THEN
will also like
?DO ... WHILE ... LOOP ELSE UNLOOP 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 2015: http://www.rigwit.co.uk/EuroForth2015/
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-10 08:11 -0800 |
| Message-ID | <65f7e2f0-fb62-4ff2-8082-c632edf47142@googlegroups.com> |
| In reply to | #44738 |
On Sunday, January 10, 2016 at 10:42:24 AM UTC-5, Anton Ertl wrote: > ... My guess is that Chris Curl finds both variants disgusting, ... Disgusting is a little strong. I find them messy and unintuitive.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-01-10 09:42 -1000 |
| Message-ID | <UbudnZ9ZjrCPKQ_LnZ2dnUU7-KOdnZ2d@supernews.com> |
| In reply to | #44738 |
On 1/10/16 5:31 AM, Anton Ertl wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: >> On 1/9/16 6:04 AM, Chris Curl wrote: >>> Elizabeth, I was and am talking about constructs like this: >>> >>> : some-loop >>> begin do-whatever >>> yyy if break then \ this then is simple! >>> zzz if break then >>> ccc if break then >>> \ any number of other conditions with "break" >>> again >>> then do-more-whatever \ this then ... not so much >>> ; >>> I am talking about the then (or whatever other word you choose to >>> call it) after again that that needs to resolve ALL the breaks. >> >> That is easy to do providing you use BEGIN ... UNTIL or BEGIN ... WHILE >> ,,, REPEAT instead of DO, etc., and a CASE structure. Here's an example >>from one of the problem sets in Forth Application Techniques: >> >> : ?WAY ( -- ) >> BEGIN KEY DUP >> 27 = NOT WHILE \ Quit on ESCape key >> DUP 32 OR \ Set lowercase bit >> CASE >> [CHAR] i OF UP ENDOF >> [CHAR] j OF LEFT ENDOF >> [CHAR] k OF HOME ENDOF >> [CHAR] l OF RIGHT ENDOF >> [CHAR] m OF DOWN ENDOF >> SWAP DUP 32 127 WITHIN IF EMIT 0 THEN >> ENDCASE DROP CR >> REPEAT DROP ; > > This example exits on just one condition, so it's not an illustration > of a solution to the problem that Chris Curl describes. > >> Simple enough. It's just trying to mix the DO structures with the >> indefinite loops that causes trouble, and the simple solution is Don't >> Do That. > > Not sure who is trying to do that. As for using WHILE to exit a DO > loop, the only differences from using it to exit a BEGIN loop is that > you have to use UNLOOP on the exiting branch, that you must use THEN > in all cases (while in a BEGIN loop one THEN is integrated into > REPEAT), and it's non-standard. My guess is that Chris Curl finds > both variants disgusting, and people who like > > BEGIN ... WHILE ... UNTIL THEN > > will also like > > ?DO ... WHILE ... LOOP ELSE UNLOOP THEN Isn't a mixed structure what the BREAK discussion is about? The first of these is structured, the second isn't. The first is also trivially implemented, the second isn't. Cheers, Elizabet -- ================================================== 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]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-01-11 13:02 +0000 |
| Message-ID | <5693a802$0$23843$e4fe514c@news.xs4all.nl> |
| In reply to | #44741 |
"Elizabeth D. Rather" <erather@forth.com> writes: >On 1/10/16 5:31 AM, Anton Ertl wrote: >> "Elizabeth D. Rather" <erather@forth.com> writes: >>> On 1/9/16 6:04 AM, Chris Curl wrote: >>>> Elizabeth, I was and am talking about constructs like this: >>>> >>>> : some-loop >>>> begin do-whatever >>>> yyy if break then \ this then is simple! >>>> zzz if break then >>>> ccc if break then >>>> \ any number of other conditions with "break" >>>> again >>>> then do-more-whatever \ this then ... not so much >>>> ; >>>> I am talking about the then (or whatever other word you choose to >>>> call it) after again that that needs to resolve ALL the breaks. >>> >>> That is easy to do providing you use BEGIN ... UNTIL or BEGIN ... WHILE >>> ,,, REPEAT instead of DO, etc., and a CASE structure. Here's an example >>>from one of the problem sets in Forth Application Techniques: >>> >>> : ?WAY ( -- ) >>> BEGIN KEY DUP >>> 27 = NOT WHILE \ Quit on ESCape key >>> DUP 32 OR \ Set lowercase bit >>> CASE >>> [CHAR] i OF UP ENDOF >>> [CHAR] j OF LEFT ENDOF >>> [CHAR] k OF HOME ENDOF >>> [CHAR] l OF RIGHT ENDOF >>> [CHAR] m OF DOWN ENDOF >>> SWAP DUP 32 127 WITHIN IF EMIT 0 THEN >>> ENDCASE DROP CR >>> REPEAT DROP ; >> >> This example exits on just one condition, so it's not an illustration >> of a solution to the problem that Chris Curl describes. >> >>> Simple enough. It's just trying to mix the DO structures with the >>> indefinite loops that causes trouble, and the simple solution is Don't >>> Do That. >> >> Not sure who is trying to do that. As for using WHILE to exit a DO >> loop, the only differences from using it to exit a BEGIN loop is that >> you have to use UNLOOP on the exiting branch, that you must use THEN >> in all cases (while in a BEGIN loop one THEN is integrated into >> REPEAT), and it's non-standard. My guess is that Chris Curl finds >> both variants disgusting, and people who like >> >> BEGIN ... WHILE ... UNTIL THEN >> >> will also like >> >> ?DO ... WHILE ... LOOP ELSE UNLOOP THEN >Isn't a mixed structure what the BREAK discussion is about? The first of >these is structured, the second isn't. The first is also trivially >implemented, the second isn't. Interestingly, believe it or not, the second structure was added to Python recently. So being properly structured may be a matter of taste after all. >Cheers, >Elizabet 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]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-13 16:20 +0000 |
| Message-ID | <2016Jan13.172007@mips.complang.tuwien.ac.at> |
| In reply to | #44741 |
"Elizabeth D. Rather" <erather@forth.com> writes:
>On 1/10/16 5:31 AM, Anton Ertl wrote:
>> My guess is that Chris Curl finds
>> both variants disgusting, and people who like
>>
>> BEGIN ... WHILE ... UNTIL THEN
>>
>> will also like
>>
>> ?DO ... WHILE ... LOOP ELSE UNLOOP THEN
>
>Isn't a mixed structure what the BREAK discussion is about? The first of
>these is structured, the second isn't. The first is also trivially
>implemented, the second isn't.
Both are structured in the sense that they have only one entrance and
one exit (if you view them as one control structure). And both are
similarly hard to implement. For the second variant, you just have to
make sure that a do-sys can be CS-ROLLed; i.e., that it is as large as
a dest or orig.
And the BREAK discussion is about (at least at the start) having
multiple exit conditions, with different exit actions depending on the
exit condition; easier to comprehend with BREAK (or CASE ?OF ENDOF
NEXTCASE) than with BEGIN WHILE WHILE WHILE REPEAT ELSE THEN ELSE THEN
or somesuch, because the exit action is directly adjacent to the exit
condition.
- 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]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-10 14:10 -0800 |
| Message-ID | <d41ee238-3021-405e-a562-b0bb151c26da@googlegroups.com> |
| In reply to | #44730 |
On Saturday, January 9, 2016 at 12:16:18 PM UTC-7, Elizabeth D. Rather wrote: > On 1/9/16 6:04 AM, Chris Curl wrote: > > Elizabeth, I was and am talking about constructs like this: > > > > : some-loop > > begin do-whatever > > yyy if break then \ this then is simple! > > zzz if break then > > ccc if break then > > \ any number of other conditions with "break" > > again > > then do-more-whatever \ this then ... not so much > > ; > > I am talking about the then (or whatever other word you choose to > > call it) after again that that needs to resolve ALL the breaks. The good thing here is that YYY ZZZ CCC etc. can be tests of anything that you want to test. The CASE statement in ANS-Forth requires the test to be a comparison of one cell to another for equality, so it is very limited. Chris' code is good --- this is similar to what I currently do except that I put the loop inside of a function all by itself and use EXIT to get out (because ANS-Forth lacks a BREAK statement) --- I would prefer to have a BREAK rather than to use my current work-around because then the code inside of the loop can access the local variables being used outside of the loop. > That is easy to do providing you use BEGIN ... UNTIL or BEGIN ... WHILE > ,,, REPEAT instead of DO, etc., and a CASE structure. Here's an example > from one of the problem sets in Forth Application Techniques: > > : ?WAY ( -- ) > BEGIN KEY DUP > 27 = NOT WHILE \ Quit on ESCape key > DUP 32 OR \ Set lowercase bit > CASE > [CHAR] i OF UP ENDOF > [CHAR] j OF LEFT ENDOF > [CHAR] k OF HOME ENDOF > [CHAR] l OF RIGHT ENDOF > [CHAR] m OF DOWN ENDOF > SWAP DUP 32 127 WITHIN IF EMIT 0 THEN > ENDCASE DROP CR > REPEAT DROP ; Code likes this makes the entire Forth community look stupid. That book "Forth Application Techniques" drives people away from Forth because it gives the reader the impression that Forth programmers are ignorant of even the most rudimentary aspects of programming. There is some history regarding CASE. In "Forth Dimensions" there was a contest for the best CASE statement and what ended up in ANS-Forth was the winner of that contest. The ANS-Forth committee was not taking into consideration the fact that the contest required the code to be written in Forth-83 standard Forth code, rather than assembly-language. In a programming language however, low-level code such as control structures would always be written in assembly-language. There are a couple of good ways to do this: 1.) Make an array at compile-time with all the test values in it and sort the array, and a corresponding array of vectors to the corresponding code is also built. At run-time a binary-search of the array is done to find the index of the match, then this index is used to find the correct vector in the jump-table. This works well when there are a wide range of possible test values. 2.) Just like #1 except that the array of vectors is as big as all of the possible test values (for chars, as in the example code above, the array would be 256 elements in size because that is the range of all possible test values). The jump table would usually be pretty sparse. Now you don't need to do a binary search, but you just use your value that you are testing for as the index into the jump table, and you are done. This works well when there are a small range of possible test values, so you don't waste a lot of memory with a gigantic sparse jump-table. The CASE statement in ANS-Forth just compiles into nested IF statements, so it is inefficient. The CASE statement in ANS-Forth can't be implemented to use #1 or #2 above because ANS-Forth allows the test values to be calculated at run-time --- ANS-Forth doesn't require them to be constants --- also, ANS-Forth doesn't require them all to be unique, but it allows duplicates. If you are going to calculate the tests at run-time (as Chris is doing with his YYY ZZZ CCC functions) then you are better off with a BREAK statement as Chris is advocating --- Chris is a newbie at Forth, but he already knows more about Forth than the committee members --- it is not difficult to learn Forth, if a person already has some programming experience, and if the person ignores the committee.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web