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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-01-24 13:16 +1100 |
| Message-ID | <n81ce0$1lp0$1@gioia.aioe.org> |
| In reply to | #45010 |
Chris Curl wrote: > On Wednesday, January 20, 2016 at 10:29:08 PM UTC-5, HAA wrote: > > ... > > The point is that manufacturers are legally liable for what their produce. > > If their product results in serious damage and/or loss of life there will be > > consequences. If I were writing Forth commercially, I (or the comany I > > worked for) would be legally liable. It's a strong incentive to buy tools > > from an established vendor who is also legally liable. > Holy crap. Are you actually being serious? > <remainder snipped> Entirely serious. I know how difficult it is to write and maintain a full-blown Forth compiler. I've seen the hodge-podge that results when amateurs with no commercial responsibility get their fingers in. I know it because I've been there.
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-14 08:46 -0800 |
| Message-ID | <6b7b467d-b552-4581-8880-d3655769fd7e@googlegroups.com> |
| In reply to | #44862 |
On Thursday, January 14, 2016 at 6:11:28 AM UTC-5, HAA wrote: > Chris Curl wrote: > > On Wednesday, January 13, 2016 at 4:47:30 PM UTC-5, HAA wrote: > > > > > > Since SwiftForth comes with full source code at no extra cost you can > > > rewrite any high-level kernel words in assembler. The ability to fix/change > > > *anything* in a Forth compiler I would rank very high as no vendor provides > > > unlimited support. YMMV > > > > > > (I have no connection with Forth Inc other than occasional use of their > > > demo) > > > > Don't GForth and SP-Forth also include full source code? > > Yes but they also come with a string of disclaimers such as 'no guarantee', > 'no warranty', 'use at your own risk', 'no support' etc. It seems to me that if you are are writing your own primitives in assembly, you are doing so at your own risk, and you could crash the system, no matter which system you do it in.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-01-16 11:34 +1100 |
| Message-ID | <n7c369$1gkg$1@gioia.aioe.org> |
| In reply to | #44875 |
Chris Curl wrote: > On Thursday, January 14, 2016 at 6:11:28 AM UTC-5, HAA wrote: > > Chris Curl wrote: > > > On Wednesday, January 13, 2016 at 4:47:30 PM UTC-5, HAA wrote: > > > > > > > > Since SwiftForth comes with full source code at no extra cost you can > > > > rewrite any high-level kernel words in assembler. The ability to fix/change > > > > *anything* in a Forth compiler I would rank very high as no vendor provides > > > > unlimited support. YMMV > > > > > > > > (I have no connection with Forth Inc other than occasional use of their > > > > demo) > > > > > > Don't GForth and SP-Forth also include full source code? > > > > Yes but they also come with a string of disclaimers such as 'no guarantee', > > 'no warranty', 'use at your own risk', 'no support' etc. > > It seems to me that if you are are writing your own primitives in assembly, you are > doing so at your own risk, and you could crash the system, no matter which system you > do it in. It matters because not all systems are created equal despite what freeware supporters would like to believe. Waiting for a competent programmer to come along and give you something for nothing is a hope - not a choice.
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-15 20:53 -0800 |
| Message-ID | <ed62d5e9-8831-4f3e-910f-f975ac9ae296@googlegroups.com> |
| In reply to | #44898 |
On Friday, January 15, 2016 at 7:34:24 PM UTC-5, HAA wrote: > > ... It matters because not all systems are created equal ... I agree with this part at least. A community of enthusiasts in an open-source environment can result in something much more useful, portable, and worthwhile than can a closed shop whose most important goal is the company's bottom line.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-13 19:31 -0800 |
| Message-ID | <f236d24c-44fc-4a19-b4f0-1c7062959a77@googlegroups.com> |
| In reply to | #44841 |
On Wednesday, January 13, 2016 at 2:47:30 PM UTC-7, HAA wrote: > hughaguilar96@gmail.com wrote: > > ... > > see within > > 40603F 4 # EBP SUB 83ED04 > > 406042 EBX 0 [EBP] MOV 895D00 > > 406045 4 [EBP] EBX MOV 8B5D04 > > 406048 EBX NEG F7DB > > 40604A 0 [EBP] EBX ADD 035D00 > > 40604D 4 # EBP ADD 83C504 > > 406050 EBX PUSH 53 > > 406051 0 [EBP] EBX MOV 8B5D00 > > 406054 4 # EBP ADD 83C504 > > 406057 EBX NEG F7DB > > 406059 0 [EBP] EBX ADD 035D00 > > 40605C 4 # EBP ADD 83C504 > > 40605F 4 # EBP SUB 83ED04 > > 406062 EBX 0 [EBP] MOV 895D00 > > 406065 EBX POP 5B > > 406066 405F7F ( U< ) CALL E814FFFFFF > > 40606B RET C3 ok > > ... > > So, what can we say about using SwiftForth? Don't Do That! > > Since SwiftForth comes with full source code at no extra cost you can > rewrite any high-level kernel words in assembler. The ability to fix/change > *anything* in a Forth compiler I would rank very high as no vendor provides > unlimited support. YMMV > > (I have no connection with Forth Inc other than occasional use of their > demo) I wrote some SwiftForth assembly-language in the novice package (there is a SwiftForth? directive that the user sets to get this rather than the ANS-Forth equivalent). I don't feel particularly charitable toward Forth Inc. nowadays, and I'm not volunteering to do their job for them anymore.
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-01-11 09:29 +1100 |
| Message-ID | <n6uluh$15f8$1@gioia.aioe.org> |
| In reply to | #44716 |
Chris Curl wrote: > ... > 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. If so, then you will have used assembler. In assembler you will have used the control flow offered by WHILE ... THEN many, many, many times without giving it a second thought. Forth offers the same in high-level in a structured way. Why is it suddenly a problem? It's clearly not a problem for Forth programmers who use it and that would be the vast majority of them, including the professionals.
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-10 21:18 -0800 |
| Message-ID | <dbb2e6b8-c283-494a-9dcd-f76ca63184c9@googlegroups.com> |
| In reply to | #44747 |
On Sunday, January 10, 2016 at 5:28:37 PM UTC-5, HAA wrote: > Chris Curl wrote: > > ... > > 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. > > If so, then you will have used assembler. In assembler you will have > used the control flow offered by WHILE ... THEN many, many, many > times without giving it a second thought. Forth offers the same in > high-level in a structured way. Why is it suddenly a problem? > It's clearly not a problem for Forth programmers who use it and that > would be the vast majority of them, including the professionals. Yes, I have programmed in assembler. No assembler I have programmed in has WHILE or THEN instructions. Some of them have MACROS to set up similar constructs, but I have never programmed in an assembler (or any other language for that matter) that supported THEN without IF. If THEN without IF is so common, then please name a few languages that support it. Note that I am NOT talking about languages that resolve forward references, which is pretty much all THEN does, obviously, ALL languages do that. I am specifically talking about using the term THEN without a corresponding IF.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2016-01-10 21:29 -0800 |
| Message-ID | <87y4bwvg4j.fsf@nightsong.com> |
| In reply to | #44751 |
Chris Curl <ccurl609@gmail.com> writes: > I am specifically talking about using the term THEN without a > corresponding IF. Forth uses THEN in the syntactic sense of "turn left, THEN turn right". That's why it's at the end of the IF block instead of in the middle: condition IF this-stuff ELSE that-stuff THEN other stuff ; The THEN says what to do after the IF statement has finished. So it is logical that it can also be used without IF.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-01-10 20:37 -1000 |
| Message-ID | <Tcmdna8cwZsq0A7LnZ2dnUU7-eGdnZ2d@supernews.com> |
| In reply to | #44751 |
On 1/10/16 7:18 PM, Chris Curl wrote: > On Sunday, January 10, 2016 at 5:28:37 PM UTC-5, HAA wrote: >> Chris Curl wrote: >>> ... >>> 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. >> >> If so, then you will have used assembler. In assembler you will have >> used the control flow offered by WHILE ... THEN many, many, many >> times without giving it a second thought. Forth offers the same in >> high-level in a structured way. Why is it suddenly a problem? >> It's clearly not a problem for Forth programmers who use it and that >> would be the vast majority of them, including the professionals. > > Yes, I have programmed in assembler. No assembler I have programmed in > has WHILE or THEN instructions. Some of them have MACROS to set up similar > constructs, but I have never programmed in an assembler (or any other language > for that matter) that supported THEN without IF. If THEN without IF is so > common, then please name a few languages that support it. Note that I am NOT > talking about languages that resolve forward references, which is pretty much > all THEN does, obviously, ALL languages do that. I am specifically talking about > using the term THEN without a corresponding IF. > It's really a matter of how you think about it. THEN completes a simple forward branch. In Forth, the eligible forward branches include IF, ELSE, and WHILE. Incidentally, the assemblers written in Forth as pioneered by Chuck since the early 70's included (and, at least in FORTH, Inc. usage, still include) structure macros, depending on the particular instruction set involved. Most include IF ... ELSE ... THEN and BEGIN ... UNTIL, and some have more depending on the processor's branch instructions. IF, etc., in assembler do not test the top stack item, but merely assemble a conditional branch. 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 | Gerry Jackson <gerry@jackson9000.fsnet.co.uk> |
|---|---|
| Date | 2016-01-11 09:05 +0000 |
| Message-ID | <n6vr49$g4i$1@dont-email.me> |
| In reply to | #44751 |
On 11/01/2016 05:18, Chris Curl wrote: > On Sunday, January 10, 2016 at 5:28:37 PM UTC-5, HAA wrote: >> Chris Curl wrote: >>> ... >>> 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. >> >> If so, then you will have used assembler. In assembler you will have >> used the control flow offered by WHILE ... THEN many, many, many >> times without giving it a second thought. Forth offers the same in >> high-level in a structured way. Why is it suddenly a problem? >> It's clearly not a problem for Forth programmers who use it and that >> would be the vast majority of them, including the professionals. > Yes, I have programmed in assembler. No assembler I have programmed in > has WHILE or THEN instructions. Some of them have MACROS to set up similar > constructs, but I have never programmed in an assembler (or any other language > for that matter) that supported THEN without IF. If THEN without IF is so > common, then please name a few languages that support it. Note that I am NOT > talking about languages that resolve forward references, which is pretty much > all THEN does, obviously, ALL languages do that. I am specifically talking about > using the term THEN without a corresponding IF. > Why not simply define an alternative name to THEN that you do like : alternative-name postpone then ; immediate -- Gerry
[toc] | [prev] | [next] | [standalone]
| From | "HAA" <someone@microsoft.com> |
|---|---|
| Date | 2016-01-12 12:26 +1100 |
| Message-ID | <n71kne$16tj$1@gioia.aioe.org> |
| In reply to | #44751 |
Chris Curl wrote:
> On Sunday, January 10, 2016 at 5:28:37 PM UTC-5, HAA wrote:
> > Chris Curl wrote:
> > > ...
> > > 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.
> >
> > If so, then you will have used assembler. In assembler you will have
> > used the control flow offered by WHILE ... THEN many, many, many
> > times without giving it a second thought. Forth offers the same in
> > high-level in a structured way. Why is it suddenly a problem?
> > It's clearly not a problem for Forth programmers who use it and that
> > would be the vast majority of them, including the professionals.
> Yes, I have programmed in assembler. No assembler I have programmed in
> has WHILE or THEN instructions.
Asm programmers use labels to emulate them:
; BEGIN test1 WHILE test2 WHILE ... REPEAT exit2 THEN exit1
loop: <test1>
jz exit1
<test2>
jz exit2
...
jmp loop
exit2: <do-exit2-stuff>
exit1: <continue>
Asm programmers don't worry this falls outside the narrow structured
programming concepts formulated in the 1960's. They use it because it's
useful and efficient.
> please name a few languages that support it. Note that I am NOT
> talking about languages that resolve forward references, which is pretty much
> all THEN does, obviously, ALL languages do that. I am specifically talking about
> using the term THEN without a corresponding IF.
Well this is Forth. Presumably you are here because you're interested in
what Forth has to offer.
Did I mention many Forth assemblers offer structured conditionals including
WHILE ... THEN :)
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-10 14:18 -0800 |
| Message-ID | <a58395ab-2e37-48f2-9a2f-dee031f479db@googlegroups.com> |
| In reply to | #44700 |
On Friday, January 8, 2016 at 7:15:28 PM UTC-7, Elizabeth D. Rather wrote: > 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: > >> 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!!!" You really don't have any right to lecture people on how to program, because you have never written a program in your life. Yelling at people that their code is "Poor Factoring!!!" is offensive. Shut up, stupid!
[toc] | [prev] | [next] | [standalone]
| From | Raimond Dragomir <raimond.dragomir@gmail.com> |
|---|---|
| Date | 2016-01-08 23:31 -0800 |
| Message-ID | <5570b279-a726-456c-8a89-c5c79412f83c@googlegroups.com> |
| In reply to | #44699 |
> 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. > I'm working on a forth application. Quite a big one. I felt the need of a BREAK word several times until now. Another example: I need a lot of tables of strings. Tables that contain among other things, a string pointer, not the string content which is variable. The solution was something like: : mystr1 s" my str 1" ; \ adr len : mystr2 s" my str 2" ; etc. Then the table : const strTable .... , mystr1 , , \ the order is: len adr .... , mystr2 , , etc. The thing is: I don't have a way of laying down the string table without naming every string... A posible solution could be: const myTable ... s" my str 1" $, ... s" my str 2" $, or: ... ,$" my str 1" ... ,$" my str 2" where $, will compile only len and adr of the string in the table, deferring the real string content compilation after the table (or before). Is the compiler more complicated? yes. But is the application programming simpler? A lot more. Think about having hundreds of string names like that. The good news is that the compiler is mine, so if I need something I can implement it.
[toc] | [prev] | [next] | [standalone]
| From | Chris Curl <ccurl609@gmail.com> |
|---|---|
| Date | 2016-01-09 08:09 -0800 |
| Message-ID | <38008c61-c45c-4c30-9093-af8b966ee8ed@googlegroups.com> |
| In reply to | #44718 |
On Saturday, January 9, 2016 at 2:31:04 AM UTC-5, Raimond Dragomir wrote: > I'm working on a forth application. Quite a big one. I felt the need of > a BREAK word several times until now. > Another example: I need a lot of tables of strings. Tables that contain > among other things, a string pointer, not the string content which is > variable. The solution was something like: > : mystr1 s" my str 1" ; \ adr len > : mystr2 s" my str 2" ; > etc. > Then the table : > const strTable > .... , mystr1 , , \ the order is: len adr > .... , mystr2 , , > etc. > The thing is: I don't have a way of laying down the string table without > naming every string... > A posible solution could be: > const myTable > ... s" my str 1" $, > ... s" my str 2" $, > or: > ... ,$" my str 1" > ... ,$" my str 2" > where $, will compile only len and adr of the string in the table, > deferring the real string content compilation after the table (or > before). > Is the compiler more complicated? yes. > But is the application programming simpler? A lot more. > Think about having hundreds of string names like that. > The good news is that the compiler is mine, so if I need something > I can implement it. I have a word called :NONAME that would give me that sort of functionality. I would be surprised if the Forth you are using cannot support what you are looking for. But even if not, then I would be even more surprised if it couldn't let you define a word that gives you what you want.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-01-09 05:31 -0600 |
| Message-ID | <l86dncXTF8w9cg3LnZ2dnUU78VWdnZ2d@supernews.com> |
| In reply to | #44699 |
Chris Curl <ccurl609@gmail.com> wrote: > 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. That's really not true, whatever you suspect. Originally (i.e. before fig-FORTH) the WHILE structure was BEGIN ... IF ... AGAIN For polyFORTH II, Dean Sanderson designed WHILE so that it could break out of *any* control structure. This property of WHILE is mentioned in Thinking FORTH. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2016-01-09 07:52 -0600 |
| Message-ID | <D8ednXwxbeIWjQzLnZ2dnUU78QudnZ2d@supernews.com> |
| In reply to | #44719 |
Andrew Haley <andrew29@littlepinkcloud.invalid> wrote: > > That's really not true, whatever you suspect. Originally (i.e. before > fig-FORTH) the WHILE structure was > > BEGIN ... IF ... AGAIN > > For polyFORTH II, Dean Sanderson designed WHILE so that it could break > out of *any* control structure. This property of WHILE is mentioned > in Thinking FORTH. To clarify, the fig-FORTH WHILE and REPEAT were approximately (sans compiler security) : while [compile] if ; : repeat swap [compile] again [compile] endif ; and the polyFORTH II version was : while [compile] if swap ; : repeat [compile] again [compile] endif ; The only significant difference is that the SWAP is in the WHILE, and that is why WHILE can be used in other kinds of structures. Forth Inc had been using this for some time, and it won the day at ANS. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2016-01-09 18:22 +0200 |
| Message-ID | <n6rbub$pjl$1@dont-email.me> |
| In reply to | #44691 |
On 08/01/2016 16:55, 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. Exactly. 8th has a 'break' word (though no 'continue'), and its action is to make the while or again or other iterator stop ... it does not act like the C construct, exiting the iterator at that point. Instead, it acts as a flag which the iterators check.
[toc] | [prev] | [next] | [standalone]
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Date | 2016-01-09 16:29 +0000 |
| Message-ID | <2016Jan9.172958@mips.complang.tuwien.ac.at> |
| In reply to | #44691 |
Raimond Dragomir <raimond.dragomir@gmail.com> writes:
>Why not another word which is missing: CONTINUE
Gforth (development version) has CONTOF: it concludes an OF/?OF clause
and jumps back to the CASE.
- 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 | stephen@mpeforth.com (Stephen Pelc) |
|---|---|
| Date | 2016-01-08 11:23 +0000 |
| Message-ID | <568f9b94.1958323170@news.eternal-september.org> |
| In reply to | #44685 |
On Fri, 8 Jan 2016 02:55:19 -0800 (PST), Raimond Dragomir
<raimond.dragomir@gmail.com> wrote:
>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.
That looks almost like
CASE
test1 OF ... ENDOF
test2 OF ... ENDOF
NEXTCASE
and all the infrastructure is already present in most systems.
As I have said before, once you have such facilities, you will
probably find find that are not used enough to justify their
existence.
Stephen
--
Stephen Pelc, stephenXXX@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-01-10 20:17 -0800 |
| Message-ID | <ad7a5711-f46b-4362-ac85-166d82804be3@googlegroups.com> |
| In reply to | #44701 |
On Friday, January 8, 2016 at 8:58:37 PM UTC-7, Stephen Pelc wrote: > On Fri, 8 Jan 2016 02:55:19 -0800 (PST), Raimond Dragomir > <raimond.dragomir@gmail.com> wrote: > > >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. > > That looks almost like > CASE > test1 OF ... ENDOF > test2 OF ... ENDOF > NEXTCASE > > and all the infrastructure is already present in most systems. > As I have said before, once you have such facilities, you will > probably find find that are not used enough to justify their > existence. I never heard of NEXTCASE before. This is because I never did RTFM the VFX manual, as you have repeatedly told me to do. Maybe the reason why these facilities aren't used is because people don't want vendor lock-in with VFX --- they are trying to write ANS-Forth code for portability --- ANS-Forth code isn't very portable though, so they might as well just give up and accept vendor lock-in. You are on the Forth-200x committee, but you seem happy to let the standard language fail to support portable code --- I think you want a weak standard so that you can tell your customers: "You can't do what you want in standard Forth, so you will just have to bite the bullet and use accept vendor lock-in with VFX --- gosh, there just isn't any choice! --- it isn't my fault!" But, of course, it is your fault because you are on the Forth-200x committee --- no doubt you will blame the plebs on the mailing list though. Anyway, your CASE ... NEXTCASE isn't as robust as Raimond's BREAK because you require the test to be a comparison of two cells, whereas in Raimond's system the test can be anything --- if you are going to require the test to be a comparison of two cells, then you would be better off with a jump-table as I described earlier.
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web