Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #31555 > unrolled thread
| Started by | JUERGEN <epldfpga@aol.com> |
|---|---|
| First post | 2014-06-15 07:06 -0700 |
| Last post | 2014-08-12 03:51 -0700 |
| Articles | 20 on this page of 143 — 27 participants |
Back to article view | Back to comp.lang.forth
FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-15 07:06 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-15 08:48 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-15 23:43 +0100
Re: FORTH LITE TUTORIAL based on MPE VFX rickman <gnuarm@gmail.com> - 2014-06-15 19:44 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-16 02:21 +0200
Re: FORTH LITE TUTORIAL based on MPE VFX Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-16 09:26 +0100
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-17 04:06 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX rickman <gnuarm@gmail.com> - 2014-06-15 19:39 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-15 23:01 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-17 09:27 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-17 20:12 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-17 21:15 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-17 22:34 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-17 23:11 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-18 16:57 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-20 05:03 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-20 14:56 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-20 17:03 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-20 17:53 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-21 10:57 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-21 11:06 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-21 13:30 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-21 11:58 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-21 14:22 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-21 20:13 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-21 21:54 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX bruce.mcfarling@gmail.com - 2014-06-21 22:31 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-22 05:31 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-22 07:04 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-22 18:02 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-23 02:53 +0200
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-22 20:29 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-22 13:40 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-22 12:08 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX november.nihal@gmail.com - 2014-06-22 16:03 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-22 20:30 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-26 15:17 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-26 15:51 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-26 22:49 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-27 07:32 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-27 23:01 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-28 06:59 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Julian Fondren <julian.fondren@gmail.com> - 2014-06-28 08:07 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-28 08:34 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-28 07:23 -1000
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-28 22:46 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-07-27 02:06 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-28 07:31 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-07-28 11:23 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-07-28 19:21 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-28 20:59 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX visualforth@rocketmail.com - 2014-07-29 11:10 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX stephenXXX@mpeforth.com (Stephen Pelc) - 2014-07-29 09:45 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-29 07:44 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX stephenXXX@mpeforth.com (Stephen Pelc) - 2014-07-29 17:48 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-07-29 11:14 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX mhx@iae.nl - 2014-07-29 12:57 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-07-29 18:36 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-29 20:38 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-07-29 21:43 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-29 23:05 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-07-30 22:20 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Raimond Dragomir <raimond.dragomir@gmail.com> - 2014-07-31 00:19 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Mark Wills <markwills1970@gmail.com> - 2014-07-30 01:41 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-07-30 21:42 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Mark Wills <markwills1970@gmail.com> - 2014-07-31 01:08 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-07-31 20:25 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Mark Wills <markwills1970@gmail.com> - 2014-08-01 02:23 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Lars Brinkhoff <lars.spam@nocrew.org> - 2014-08-01 12:54 +0200
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-08-01 19:57 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-08-02 04:18 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-07-27 02:14 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX bruce.mcfarling@gmail.com - 2014-06-21 21:59 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-06-21 22:36 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-21 22:44 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Julian Fondren <julian.fondren@gmail.com> - 2014-06-22 02:26 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-22 07:41 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-22 07:43 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-22 19:57 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-24 21:04 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-24 15:21 -1000
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-25 18:21 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-25 03:16 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX Ron Aaron <rambamist@gmail.com> - 2014-06-25 12:08 +0300
Re: FORTH LITE TUTORIAL based on MPE VFX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-25 14:08 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX Ron Aaron <rambamist@gmail.com> - 2014-06-25 19:13 +0300
Re: FORTH LITE TUTORIAL based on MPE VFX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-25 17:14 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX Ron Aaron <rambamist@gmail.com> - 2014-06-25 21:03 +0300
Re: FORTH LITE TUTORIAL based on MPE VFX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-26 12:13 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-25 16:14 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2014-06-25 17:27 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-25 18:24 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-26 03:27 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-26 17:50 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Andrew Haley <andrew29@littlepinkcloud.invalid> - 2014-06-27 03:13 -0500
Re: FORTH LITE TUTORIAL based on MPE VFX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-27 12:30 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX Mark Wills <markwills1970@gmail.com> - 2014-06-25 03:46 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX albert@spenarnc.xs4all.nl (Albert van der Horst) - 2014-06-25 16:15 +0000
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-25 13:19 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-25 18:52 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Alexander Skobelev <al.skobelev@gmail.com> - 2014-06-26 10:45 +0400
Re: FORTH LITE TUTORIAL based on MPE VFX Ron Aaron <rambamist@gmail.com> - 2014-06-26 09:56 +0300
Re: FORTH LITE TUTORIAL based on MPE VFX Alexander Skobelev <al.skobelev@gmail.com> - 2014-06-26 11:30 +0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-25 18:38 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-25 20:49 -1000
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-26 17:54 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX David Thompson <dave.thompson2@verizon.net> - 2014-07-26 21:53 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Julian Fondren <ayrnieu@gmail.com> - 2014-06-22 22:22 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-23 07:31 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-24 17:05 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-24 20:55 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-24 19:52 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-25 13:09 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX humptydumpty <ouatubi@gmail.com> - 2014-06-23 00:17 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX humptydumpty <ouatubi@gmail.com> - 2014-06-23 00:27 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-23 07:45 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-23 07:54 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX humptydumpty <ouatubi@gmail.com> - 2014-06-24 00:56 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Bernd Paysan <bernd.paysan@gmx.de> - 2014-06-27 03:33 +0200
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-25 18:20 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-25 18:50 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-25 20:00 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-25 23:02 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Paul E Bennett <Paul_E.Bennett@topmail.co.uk> - 2014-06-26 10:28 +0100
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-26 07:56 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Elizabeth D. Rather" <erather@forth.com> - 2014-06-26 07:59 -1000
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-26 17:33 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-26 17:26 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-26 17:22 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-18 22:07 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Julian Fondren <julian.fondren@gmail.com> - 2014-06-18 19:28 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX mhx@iae.nl - 2014-06-18 23:09 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX hughaguilar96@yahoo.com - 2014-06-18 20:02 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-06-19 18:28 -0400
Re: FORTH LITE TUTORIAL based on MPE VFX Julian Fondren <julian.fondren@gmail.com> - 2014-06-17 21:01 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX mhx@iae.nl - 2014-06-17 23:01 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX jyf <jyf1987@gmail.com> - 2014-06-19 22:13 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX Roger Levy <roger.levy@gmail.com> - 2014-06-19 22:34 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX brelliott18@hotmail.com - 2014-08-10 09:15 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-08-11 14:31 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-08-11 23:51 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX brelliott18@hotmail.com - 2014-08-12 03:14 -0700
Re: FORTH LITE TUTORIAL based on MPE VFX JUERGEN <epldfpga@aol.com> - 2014-08-12 03:51 -0700
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | Roger Levy <roger.levy@gmail.com> |
|---|---|
| Date | 2014-06-21 11:06 -0700 |
| Message-ID | <31f28699-46bc-4f5b-a1f2-565d663dfd3e@googlegroups.com> |
| In reply to | #31711 |
> What did I say about all-or-nothing things? Nothing. But it seemed to be implied in your argument that defining a general purpose array is somehow inherently wrong. Then again, Hugh didn't post what you replied to. This aspect of the discussion on who-said-what is kind of a waste of time. I'm not for or against anyone, and really don't care what side who is on. But, I just read the spec for BUFFER: and why you mentioned this is frankly puzzling. There doesn't seem to be anything in here having to do with general-purpose arrays, and by that I mean ones that "know" the size of the stored datatype or have niceties like the words for treating them as stacks (as my personal wordset does). The word "array" is not even mentioned once on the page. How does this support general-purpose arrays more than ALLOT?
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-06-21 13:30 -0500 |
| Message-ID | <8bGdnfzw1fKiUjjOnZ2dnUVZ_qWdnZ2d@supernews.com> |
| In reply to | #31713 |
On 6/21/14 1:06 PM, Roger Levy wrote: > >> What did I say about all-or-nothing things? > > Nothing. But it seemed to be implied in your argument that defining a general purpose array is somehow inherently wrong. > > Then again, Hugh didn't post what you replied to. This aspect of the discussion on who-said-what is kind of a waste of time. I'm not for or against anyone, and really don't care what side who is on. > > But, I just read the spec for BUFFER: and why you mentioned this is frankly puzzling. There doesn't seem to be anything in here having to do with general-purpose arrays, and by that I mean ones that "know" the size of the stored datatype or have niceties like the words for treating them as stacks (as my personal wordset does). The word "array" is not even mentioned once on the page. How does this support general-purpose arrays more than ALLOT? > The problem is, what is a "general purpose array"? You envision a set of requirements which, though easy to implement, haven't been requirements for most of the arrays I've worked with, and omits one of my favorite features (takes an index and returns the indexed address). BUFFER: (which, I agree, is mostly syntactic sugar for ALLOT) is sort of the "least common denominator." So long as there are multiple concepts of a "general purpose array," and all of them easy to implement in a couple of lines of code, it's likely that many of us would rather just implement our favorite rather than stress over what features a "standard" version should have. On Day 4 of my introductory Forth course students implement a couple of different flavors of arrays. It usually takes them an hour or so. Having gotten the general idea, in the future it will take ~5 mins, and they'll have exactly the behavior they want. What's wrong with 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 | Roger Levy <roger.levy@gmail.com> |
|---|---|
| Date | 2014-06-21 11:58 -0700 |
| Message-ID | <5b2794b8-8708-4bd2-bd20-f5fca5ea5402@googlegroups.com> |
| In reply to | #31715 |
> The problem is, what is a "general purpose array"? You envision a set of > requirements which, though easy to implement, haven't been requirements > for most of the arrays I've worked with, and omits one of my favorite > features (takes an index and returns the indexed address). BUFFER: > (which, I agree, is mostly syntactic sugar for ALLOT) is sort of the > "least common denominator." I'm going to pass by the mention of that specific feature of taking an index and turning it into an address. Not sure how it's relevant. In my mind, BUFFER: defines a buffer - period. You can't go saying that it's a general purpose array - it's not. It is certainly not a general purpose array by the range of definitions I think everyone except you would agree on. It isn't even really an array of any kind until you define the interface to make it one, whether that's a special-purpose one or a general-purpose one. This can be argued with people who do address math in application code - I prefer more encapsulation for myself (don't confuse this with how encapsulated I think Forth should be - Forth is fine the way it is.) > So long as there are multiple concepts of a "general purpose array," and > all of them easy to implement in a couple of lines of code, it's likely > that many of us would rather just implement our favorite rather than > stress over what features a "standard" version should have. I didn't know we were discussing a standardized one. If we were, then I don't want one for Forth as a whole. I am of the opinion that thanks to wordlists, one day people could have a choice of solid high-level-application toolbelts to use for their projects, even mix-and-match in the same project as practical. Maybe that could be more viable if someone came up with a way to make that convenient and easy to understand. I don't know - haven't done any research on this idea. From what I understood, the point of the discussion is that there's value in implementing our own general purpose arrays for our own "toolbelts" (per project or codebase). I don't think having a standard one in Forth is possible or desirable; too many assumptions would have to be made. I think you see Forth as a language standard. Correct me if I'm wrong. Personally, I see it as a language DESIGN standard. We can and SHOULD be talking about languages built on top of Forth now - maybe that's the way to bring Forth into modernity without losing any of its core capabilities. The means and methodologies of doing this without "burying" any of those capabilities is an interesting problem IMO. > On Day 4 of my introductory Forth course students implement a couple of > different flavors of arrays. It usually takes them an hour or so. Having > gotten the general idea, in the future it will take ~5 mins, and they'll > have exactly the behavior they want. What's wrong with that? Absolutely nothing! :)
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-06-21 14:22 -0500 |
| Message-ID | <vpidnbmANvflRjjOnZ2dnUVZ_v6dnZ2d@supernews.com> |
| In reply to | #31716 |
On 6/21/14 1:58 PM, Roger Levy wrote: > From what I understood, the point of the discussion is that there's value in implementing our own general purpose arrays for our own "toolbelts" (per project or codebase). I don't think having a standard one in Forth is possible or desirable; too many assumptions would have to be made. > > I think you see Forth as a language standard. Correct me if I'm wrong. Personally, I see it as a language DESIGN standard. We can and SHOULD be talking about languages built on top of Forth now - maybe that's the way to bring Forth into modernity without losing any of its core capabilities. The means and methodologies of doing this without "burying" any of those capabilities is an interesting problem IMO. Ok, perhaps I did misunderstand. I saw the topic as, "One of the big deficiencies of Forth is that it doesn't have a 'general purpose array.'" If you're talking about Forth in general that way, the only way to fix such a "deficiency" is to standardize the "missing" feature. I completely agree with your first paragraph quoted above. 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-06-21 20:13 -0700 |
| Message-ID | <fccfc4be-63a2-457e-9425-326ddba93e7b@googlegroups.com> |
| In reply to | #31715 |
On Saturday, June 21, 2014 11:30:24 AM UTC-7, Elizabeth D. Rather wrote: > The problem is, what is a "general purpose array"? You envision a set of > requirements which, though easy to implement, haven't been requirements > for most of the arrays I've worked with, and omits one of my favorite > features (takes an index and returns the indexed address). You are asking, "what is a general purpose array?," because you don't know the answer. Also, all arrays return the address of the element given the index --- I did not omit this feature --- you have never looked at my novice package, and it is all over your head anyway, so you just make up a lot of lies about it. > So long as there are multiple concepts of a "general purpose array," and > all of them easy to implement in a couple of lines of code, it's likely > that many of us would rather just implement our favorite rather than > stress over what features a "standard" version should have. Show us these "couple of lines of code" that are so easy to implement --- I'm looking forward to the first time ever that you post code on comp.lang.forth --- posting a snippet of code from "Starting Forth" is all that you have ever done. You are totally faking it as a programmers --- you have never written any Forth software in your life, not even a couple of lines of code. > On Day 4 of my introductory Forth course students implement a couple of > different flavors of arrays. It usually takes them an hour or so. Having > gotten the general idea, in the future it will take ~5 mins, and they'll > have exactly the behavior they want. What's wrong with that? Your class is based entirely on "Starting Forth" --- does it really take 4 days to read that book? --- are your students illiterate, so they need a kindergarten teacher to read to them while they sit in a semi-circle on the floor? This business of writing everything from scratch every time, is stupid. This limits the programmer to only the most simple data-structures, such as arrays and linked-lists, and to never graduate to anything that is too complicated to be implemented ~5 minutes. Also, the data-structure code gets mixed in with the application code, so the application code becomes bloated and difficult to read. The idea with "information hiding" is that low-level code is separated from high-level code, rather than mixed together, so the high-level code is more readable. This is Programming-101 --- everybody knows this stuff --- except you. What is wrong with stupidity??? Well, you make the entire Forth community look stupid --- because Forth Inc. owns the name "Forth" and so it is easy for Forth's detractors to claim that Forth Inc. represents Forth, and that all Forth programmers are at your level of incompetence. You describe yourself as the "leading expert" on Forth. Mostly, it is the C programmers who trumpet this idea --- because they can count on you to make the Forth community look stupid on a daily basis, which indirectly makes C look good --- you personally are the reason why Forth failed in the late 1980s.
[toc] | [prev] | [next] | [standalone]
| From | Roger Levy <roger.levy@gmail.com> |
|---|---|
| Date | 2014-06-21 21:54 -0700 |
| Message-ID | <2555af92-2741-4788-b672-086a7e92ae28@googlegroups.com> |
| In reply to | #31728 |
Oh the humanity!!! :P > You are asking, "what is a general purpose array?," because you don't know the answer. I think, she made a fair point. Not a mind blowing revelation, but a well-trodden "wisdom". No one who does Forth can point to a standard formal definition of a general purpose array. But that's splitting hairs; I think it's easy to "understand" the idea of a general purpose array, totally separate from details or flavors. Do you argue for a general purpose array for all of Forth-dom? I'm a little unclear on that. > Show us these "couple of lines of code" that are so easy to implement I'll do it! :) : array create cells allot ; : th cells + ; > --- I'm looking forward to the first time ever that you post code on comp.lang.forth If it's true that Elizabeth has never posted original self-written code not from a book, oof. That'd be a dooz. I haven't been paying attention long enough. > Your class is based entirely on "Starting Forth" --- does it really take 4 days to read that book? --- are your students illiterate, so they need a kindergarten teacher to read to them while they sit in a semi-circle on the floor? Heh. What I'd like to know is when was the last time this class was held? > This business of writing everything from scratch every time, is stupid. Hear, hear. It only makes sense in embedded apps or if you're seeking Nirvana through code perfection. I find nothing wrong in striking a balance and not spending a day perfecting a hard disk driver ;) Some of us like to play with big somewhat-wasteful-but-flexible legos. So long as you don't turn Forth into C#, I think it's okay. > The idea with "information hiding" is that low-level code is separated from high-level code, rather than mixed together, so the high-level code is more readable. This is Programming-101 --- everybody knows this stuff --- except you. And a cut to the jaw! Ouch! Well, I'm not sure the division is THAT sharp - yeah, too many assumptions about how memory is laid out is bad, but, I'm sure that you can get away with a bunch of things. You don't need to encapsulate EVERYTHING with something new, sometimes basic primitives do the job fine. I say SOMETIMES. For example a constant, *, +, @, and ! might be enough in some cases, but using @ to mean "follow link to next object" or CELL- to mean "get at a piece of metadata" might not be good. Application level almost definitely not. If the application wordset is simple enough and all in one file, it might be okay. It all depends. I've gotten migraines untangling some SwiftForth definitions. The internals of the system has equal parts good and mind-blowingly horrible decisions as it pertains to accommodating change. But when you have a big complex thing sometimes you're kind of stuck with it. Someone needs to write an article or book on this, it's one of those dark arts. How To Not Shoot Yourself In Foot, for Forth Programmers. > What is wrong with stupidity??? Well, you make the entire Forth community look stupid --- because Forth Inc. owns the name "Forth" and so it is easy for Forth's detractors to claim that Forth Inc. represents Forth, and that all Forth programmers are at your level of incompetence. > You describe yourself as the "leading expert" on Forth. Mostly, it is the C programmers who trumpet this idea --- because they can count on you to make the Forth community look stupid on a daily basis, which indirectly makes C look good --- you personally are the reason why Forth failed in the late 1980s. These claims need evidence... but ... maybe it's not that Elizabeth is making the Forth community look stupid, just that no one is making it look smart? I'm not scared of dumb C programmers, dime a dozen, but I am scared of there being too many dumb Forth ones. FORTH Inc. may have failed but I don't think they didn't sincerely try. As for Elizabeth I have no idea if she really is a programmer; no one has refuted or confirmed your claims so far. You've rallied against ANS. I think the standard, or at least the quest for one, is a good thing. It dispels the idea that Forth has no standard, which is kind of crucial. Sure you can get some more code purity out of starting from complete scratch, but we're writing desktop applications. You need to accept some perfection-sacrifices to deal with OS's. Standards always have an element of suck. OpenGL in particular comes to mind. It's not perfect but it's a way to be taken seriously. We just need to figure out the best way to work with it. The cruft will get weeded out over time. Jumping around, I will say that the spirit behind BUFFER: is right. It would be a good idea for everyone to be able to rely on something that works better on more architectures, but maybe BUFFER: isn't it. Why not just allow for systems to compile code in a separate 2nd dictionary, and put in a requirement that application code can't assume there's only one dictionary? Does anyone really need to be mixing code and data in the same area? Maybe someone might want to do some weird code-level stuff - provide a flag to let them toggle between, if they care about cache performance - if not, business as usual. In my Gamecube Forth (GC Forth, terrible name) I aligned code and CREATE bodies to boundaries of some size I can't remember. You got different cache behavior (writethru and writeback) depending on a high bit in the address, and I used the writeback mode for code, so they were effectively separate. It was all transparent to the user, IIRC.
[toc] | [prev] | [next] | [standalone]
| From | bruce.mcfarling@gmail.com |
|---|---|
| Date | 2014-06-21 22:31 -0700 |
| Message-ID | <3ab505fc-137e-4e76-bd40-bd025ece37e4@googlegroups.com> |
| In reply to | #31729 |
On Sunday, June 22, 2014 12:54:44 AM UTC-4, Roger Levy wrote: > Why not just allow for systems to compile code in a separate 2nd dictionary, and put in a requirement that application code can't assume there's only one dictionary? Does anyone really need to be mixing code and data in the same area? I didn't catch the jump here. There's no assumption that code and data and names are mixed ... its a common implementation approach, but its perfectly possible to have: Data -> up .... down <- Heap | Code -> up ... down <- Names Hence words like COMPILE, and , which in mixed classic threaded systems may be: : HERE ( -- a ) DP @ ; : , ( x -- ) HERE ! DP ++ ; : COMPILE, ( xt -- ) , ; ... and on split classic implementations may be: : HERE ( -- a ) DP @ ; : , ( x -- ) HERE ! DP ++ ; : CODE-HERE ( -- a ) CP @ ; : COMPILE, ( xt -- ) CODE-HERE ! CP ++ ; ... so while COMPILE, is often about things like compiling the call along with the routine address in a subroutine threaded Forth, it's also part of the separation of codespace and dataspace. And of course, in many umbilical Forths, the namespace stays on the host machine, and only specific names required for operational purposes are ever compiled onto the target system. In general ANS Forth provides the words that allow us to refrain from assuming that we are mixing code and data in the same area. > Maybe someone might want to do some weird code-level stuff - provide a flag to let them toggle between, if they care about cache performance - if not, business as usual. That also seems a fairly conventional thing ~ specific implementation specific features accessed via implementation specific flags or prefix or postfix operators. Though it seems like the multi-processor Forth systems have been more successful in maintaining ongoing support on decade plus time scales, and it may be that the single processor implementations are more inclined to focus on providing that kind of tailoring.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2014-06-22 05:31 -0500 |
| Message-ID | <iq-dnWGbsvLtLTvOnZ2dnUVZ_sydnZ2d@supernews.com> |
| In reply to | #31729 |
Roger Levy <roger.levy@gmail.com> wrote: > No one who does Forth can point to a standard formal definition of a > general purpose array. But that's splitting hairs; I think it's > easy to "understand" the idea of a general purpose array, totally > separate from details or flavors. > >> Show us these "couple of lines of code" that are so easy to implement > > I'll do it! :) > > : array create cells allot ; > : th cells + ; Well, yes. That's a simple one if you want an array that's statically allocated in the dictionary, so it can't be grown or shrunk, can't be in a file, etc, etc. So, for what it's worth, I don't know what a "general-purpose array" is either. > Jumping around, I will say that the spirit behind BUFFER: is right. > It would be a good idea for everyone to be able to rely on something > that works better on more architectures, but maybe BUFFER: isn't it. > Why not just allow for systems to compile code in a separate 2nd > dictionary, and put in a requirement that application code can't > assume there's only one dictionary? > Does anyone really need to be mixing code and data in the same area? Who says they have to? There's absolutely nothing to stop standard Forth systems from keeping code and data in separate regions. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Roger Levy <roger.levy@gmail.com> |
|---|---|
| Date | 2014-06-22 07:04 -0700 |
| Message-ID | <54cb4fff-7fb0-4ccd-9f5c-f1b830dc4e1b@googlegroups.com> |
| In reply to | #31736 |
> Well, yes. That's a simple one if you want an array that's statically > allocated in the dictionary, so it can't be grown or shrunk, can't be > in a file, etc, etc. So, for what it's worth, I don't know what a > "general-purpose array" is either. That was the point. A general purpose array, would be an array you use for general purposes. In Forth we don't have a standardized one. I have one, others I'm sure have their own, some people think there's no point to having one. Mine is 168 lines long, and has a couple features I ended up not using. I'm probably going to extend my wordset with optional support for dynamic arrays, and inline arrays, soon. I'm kind of waiting to see if Elizabeth has her own version or anything to say about the one I posted.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-06-22 18:02 -0500 |
| Message-ID | <JKidnfBTWtT3_TrOnZ2dnUVZ_qadnZ2d@supernews.com> |
| In reply to | #31740 |
On 6/22/14 9:04 AM, Roger Levy wrote: > >> Well, yes. That's a simple one if you want an array that's statically >> allocated in the dictionary, so it can't be grown or shrunk, can't be >> in a file, etc, etc. So, for what it's worth, I don't know what a >> "general-purpose array" is either. > > That was the point. A general purpose array, would be an array you use for general purposes. In Forth we don't have a standardized one. I have one, others I'm sure have their own, some people think there's no point to having one. Mine is 168 lines long, and has a couple features I ended up not using. I'm probably going to extend my wordset with optional support for dynamic arrays, and inline arrays, soon. > > I'm kind of waiting to see if Elizabeth has her own version or anything to say about the one I posted. > Elizabeth wishes to go on record as being horrified at *any* Forth definition being 168 lines long, regardless of what it does. 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 | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2014-06-23 02:53 +0200 |
| Message-ID | <lo7tqo$rhq$1@online.de> |
| In reply to | #31752 |
Elizabeth D. Rather wrote: > Elizabeth wishes to go on record as being horrified at *any* Forth > definition being 168 lines long, regardless of what it does. It's probably not a single definition, but distributed in read/write access, resizing, allocating, freeing, and maybe more. I've added string arrays to Gforth recently, and they are completely dynamic and nestable. You can have arrays of arrays of string arrays, and decide for each of the sub-arrays if it contains strings or arrays of strings - but you need to know what it actually is - so far I haven't added a type identifier - the nesting feature is not intentional, it's just a consequence of the implementation - I expect that users know what's an array and what's a string; for implementation simplicity, both are resizable addr u buffers, and the arrays just contain pointers where the strings contain characters. The definitions are all short, and in total, if you include the actual string handling, it's even more than 168 lines. There's stuff that reads files into arrays or writes arrays into files. That sort of stuff all need a few lines each. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-06-22 20:29 -0500 |
| Message-ID | <B-ydnTIkl515HzrOnZ2dnUVZ_jmdnZ2d@supernews.com> |
| In reply to | #31754 |
On 6/22/14 7:53 PM, Bernd Paysan wrote: > Elizabeth D. Rather wrote: > >> Elizabeth wishes to go on record as being horrified at *any* Forth >> definition being 168 lines long, regardless of what it does. > > It's probably not a single definition, but distributed in read/write access, > resizing, allocating, freeing, and maybe more. I've added string arrays to > Gforth recently, and they are completely dynamic and nestable. You can have > arrays of arrays of string arrays, and decide for each of the sub-arrays if > it contains strings or arrays of strings - but you need to know what it > actually is - so far I haven't added a type identifier - the nesting feature > is not intentional, it's just a consequence of the implementation - I expect > that users know what's an array and what's a string; for implementation > simplicity, both are resizable addr u buffers, and the arrays just contain > pointers where the strings contain characters. > > The definitions are all short, and in total, if you include the actual > string handling, it's even more than 168 lines. There's stuff that reads > files into arrays or writes arrays into files. That sort of stuff all need > a few lines each. > I fervently hope that you're right! 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 | albert@spenarnc.xs4all.nl (Albert van der Horst) |
|---|---|
| Date | 2014-06-22 13:40 +0000 |
| Message-ID | <53a6dcb2$0$4648$e4fe514c@dreader36.news.xs4all.nl> |
| In reply to | #31729 |
In article <2555af92-2741-4788-b672-086a7e92ae28@googlegroups.com>,
Roger Levy <roger.levy@gmail.com> wrote:
>Oh the humanity!!! :P
>
>> You are asking, "what is a general purpose array?," because you don't
>know the answer.
>
>I think, she made a fair point. Not a mind blowing revelation, but a
>well-trodden "wisdom". No one who does Forth can point to a standard
>formal definition of a general purpose array. But that's splitting
>hairs; I think it's easy to "understand" the idea of a general purpose
>array, totally separate from details or flavors.
>
>Do you argue for a general purpose array for all of Forth-dom? I'm a
>little unclear on that.
We could have
For a build XT and a LENGTH SIZE define a data structure of length objects
of SIZE.
ARRAY ( xt n -- ) does: ( n -- address )
Then we could define
' C, 100 1 ARRAY ape
' , 100 1 ARRAY ape-cell
with a does part like
DOES> @+ ROT * + ;
Watch everybody go apes about the extra multiplication, that is not needed in
CREATE APE 100 CELLS ALLOT
: ape[] CELLS APE + ;
(and save you looking up the dictionary entry for ARRAY )
Then I will not be very happy with my continued-fraction class:
I could do
class continued-fraction ..
' BUILD-continued-fraction 100 ??? ARRAY square-roots
The problem with an array like this is:
I want `` 12 square-roots '' to make that 12-th the current object, not
an address that I then must fetch, then store in the current continued-fraction
pointer.
(And it is a pain to construct the size of a c.f. hence the ??? )
>
>> Show us these "couple of lines of code" that are so easy to implement
>
>I'll do it! :)
>
>: array create cells allot ;
>: th cells + ;
>
>
That doesn't capture the array concept as in Algol 68 "row of".
It can't be a row of procedures that take a continued fraction and a number
and return a matrix. Where both cf and matrix are defined by yourself.
And certainly not the safe-guard that you store a wrong type of procedure there.
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 | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-06-22 12:08 -0500 |
| Message-ID | <jd-dnV1jiaIbkDrOnZ2dnUVZ_oCdnZ2d@supernews.com> |
| In reply to | #31729 |
On 6/21/14 11:54 PM, Roger Levy wrote:
...
>
> : array create cells allot ;
> : th cells + ;
I prefer:
: array ( n -- ) CREATE CELLS ALLOT
DOES> ( i -- a ) + ;
100 array data
...because most of the time you'll be referencing it inside a loop, and
you can just say
i data
to get the address of the ith element. Should you want the address of
the start of the array for some reason, you can always say 0 data.
>
>> --- I'm looking forward to the first time ever that you post code on comp.lang.forth
>
> If it's true that Elizabeth has never posted original self-written code not from a book, oof. That'd be a dooz. I haven't been paying attention long enough.
I have occasionally posted snippets like the above. Most of the code
I've written in the past has been proprietary code for the companies we
wrote it for.
>> Your class is based entirely on "Starting Forth" --- does it really take 4 days to read that book? --- are your students illiterate, so they need a kindergarten teacher to read to them while they sit in a semi-circle on the floor?
>
> Heh. What I'd like to know is when was the last time this class was held?
Double "Heh". I not only have never taught using Starting Forth, I have
repeatedly railed against relying on this 40-yr-old document in any way
other than historical interest or amusement. I wrote Forth Application
Techniques
http://www.amazon.com/Forth-Application-Techniques-Notebook-Edition/dp/1419685767/ref=sr_1_1?ie=UTF8&qid=1403455657&sr=8-1&keywords=Forth+Application+techniques
as the course notebook for this class, and I and other people have
taught literally hundreds of courses based on it, both publicly and for
in-house staffs at various organizations including IBM, Apple, and
others. I am retired and do not actively teach now.
>> This business of writing everything from scratch every time, is stupid.
>
> Hear, hear. It only makes sense in embedded apps or if you're seeking Nirvana through code perfection. I find nothing wrong in striking a balance and not spending a day perfecting a hard disk driver ;) Some of us like to play with big somewhat-wasteful-but-flexible legos. So long as you don't turn Forth into C#, I think it's okay.
I agree with Roger's previous observation that he and most Forth
programmers have personal "toolbelts" of words developed over time that
are useful in the application domains in which they work. And most
widely available Forths also include a lot of those features. That's a
far cry from "writing everything from scratch every time."
It would be of great benefit to Forth in general if more people would
publish their toolbelts (in Standard Forth, of course) and stop trying
to write "yet another Forth" from scratch.
...
> I've gotten migraines untangling some SwiftForth definitions. The internals of the system has equal parts good and mind-blowingly horrible decisions as it pertains to accommodating change. But when you have a big complex thing sometimes you're kind of stuck with it.
>
> Someone needs to write an article or book on this, it's one of those dark arts. How To Not Shoot Yourself In Foot, for Forth Programmers.
SwiftForth suffers greatly from having to cope with a very "big complex
thing," namely Windows. Prior systems from FORTH, Inc. were vastly
cleaner, and many parts of SwF still are. I haven't spent much time
looking at the internals of the Linux version of SwiftForth, but it
might be a lot cleaner.
...
> Jumping around, I will say that the spirit behind BUFFER: is right. It would be a good idea for everyone to be able to rely on something that works better on more architectures, but maybe BUFFER: isn't it. Why not just allow for systems to compile code in a separate 2nd dictionary, and put in a requirement that application code can't assume there's only one dictionary? Does anyone really need to be mixing code and data in the same area? Maybe someone might want to do some weird code-level stuff - provide a flag to let them toggle between, if they care about cache performance - if not, business as usual.
As others have noted, there are certainly Forths that segregate code and
data space, particularly for embedded systems that have to deal with
RAM/ROM/Flash/on-chip memory.
> In my Gamecube Forth (GC Forth, terrible name) I aligned code and CREATE bodies to boundaries of some size I can't remember. You got different cache behavior (writethru and writeback) depending on a high bit in the address, and I used the writeback mode for code, so they were effectively separate. It was all transparent to the user, IIRC.
>
Yes, a number of modern Forths (including SwiftForth) 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 | november.nihal@gmail.com |
|---|---|
| Date | 2014-06-22 16:03 -0700 |
| Message-ID | <27b6a2a1-f0f1-4d97-9a8d-637d7d5aa7fb@googlegroups.com> |
| In reply to | #31747 |
: array create cells allot does> swap cells + ;
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2014-06-22 20:30 -0500 |
| Message-ID | <B-ydnS0kl52yHjrOnZ2dnUVZ_jmdnZ2d@supernews.com> |
| In reply to | #31753 |
On 6/22/14 6:03 PM, november.nihal@gmail.com wrote: > > : array create cells allot does> swap cells + ; > Better :-) -- ================================================== 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 | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-06-26 15:17 -0700 |
| Message-ID | <c841e03e-0f7a-481d-8dc0-085416222e32@googlegroups.com> |
| In reply to | #31747 |
On Sunday, June 22, 2014 10:08:21 AM UTC-7, Elizabeth D. Rather wrote:
> On 6/21/14 11:54 PM, Roger Levy wrote:
>
> > : array create cells allot ;
> > : th cells + ;
>
> I prefer:
>
> : array ( n -- ) CREATE CELLS ALLOT
> DOES> ( i -- a ) + ;
>
> 100 array data
I think that you purposely posted non-working code in order to snub your nose at the Forth community. You are essentially saying that you are much too important to bother with anything so mundane as writing code that actually works.
Also, I explicitly said that the code as not to come from "Starting Forth" --- but this code (actually, the working version of this code) does come straight out of that book. You have NEVER posted any code on comp.lang.forth that didn't come out of "Starting Forth" --- and you usually get it messed up, like you did here.
You are not a programmer --- you have been faking it since the 1970s --- you know nothing about the subject.
> >> This business of writing everything from scratch every time, is stupid.
>
> > Hear, hear. It only makes sense in embedded apps or if you're seeking Nirvana through code perfection. I find nothing wrong in striking a balance and not spending a day perfecting a hard disk driver ;) Some of us like to play with big somewhat-wasteful-but-flexible legos. So long as you don't turn Forth into C#, I think it's okay.
>
> I agree with Roger's previous observation that he and most Forth
> programmers have personal "toolbelts" of words developed over time that
> are useful in the application domains in which they work. And most
> widely available Forths also include a lot of those features. That's a
> far cry from "writing everything from scratch every time."
This is what I said on the Forth-200x mailing list shortly before getting kicked off:
What this ["toolbelts" or "code in the back pocket"] means in practice, is that new programs are written by cut-and-pasting the source-code from old programs. For example, if an old program had an LLRB tree, then a new program that needed an LLRB tree would just get the source-code from the old program pasted into it, with the innards modified to make it work for the new data. The LLRB tree is just a humorous example, as Forth Inc. obviously doesn't use such complicated data structures --- but cut-and-paste is apparently their standard technique with arrays and linked-lists and other simple data-structures that they are capable of working with.
FODs (Foul Old Dudes) like cut-and-paste programming. They gain an advantage over the FNGs (F'ing New Guys) because they have a list of all the old programs in the archive. When a new program is needed, they can generally remember an old program that was similar, and they can cut-and-paste from that old program. By comparison, the FNG doesn't have access to the archive (or, at least, doesn't know what is in the archive because there is no available documentation), and hence has to write everything from scratch. The FOD can whip out a binary tree or whatever quite quickly, while the FNG is bogged down implementing it from scratch (often with an algorithms book open on his desk). If the FNG tries to make his code reusable, and start putting together a library, then the FODs run to the boss and complain that the FNG is spending time doing something other than writing the application program that was assigned to him, and hence deserves to be fired for wasting company time. It is all just a big scam by the FODs to stay on top and hold down the FNGs ("Old age and treachery defeat youth and skill."). This scam only works when the language does not support reusable code very well. In my experience as a machinist, this scam is standard in CNC gcode which has almost no support for reusability. I've never worked as a COBOL or Fortran programmer, but I've heard that this scam is pretty typical there too, because those languages have terrible support for reusability. I think that it is not a coincidence that Elizabeth Rather's background prior to Forth was in COBOL and Fortran --- she is trying to make Forth a haven for FODs just like COBOL and Fortran are havens for FODs (actually, were havens for FODs, because both languages have become obsolete due to the dearth of FNG volunteers). This is why Forth lacks libraries, and the lack of libraries is why Forth has a dearth of FNG volunteers --- all we have left are FODs, and there is no future in that.
[toc] | [prev] | [next] | [standalone]
| From | Roger Levy <roger.levy@gmail.com> |
|---|---|
| Date | 2014-06-26 15:51 -0700 |
| Message-ID | <1151afb8-b7e9-4a03-9048-ff45ad4f5889@googlegroups.com> |
| In reply to | #31900 |
You spend a WHOLE lot of time and effort digging things up and vilifying people. Know that? Every other post is "I was banned from some place because of this" or "these people are pure evil because of this exchange". And the quote is inflammatory in tone. Big surprise? > What this ["toolbelts" or "code in the back pocket"] means in practice, is that new programs are written by cut-and-pasting the source-code from old programs. For example, if an old program had an LLRB tree, then a new program that needed an LLRB tree would just get the source-code from the old program pasted into it, with the innards modified to make it work for the new data. Did you read that Cut-and-Paste Is Bad somewhere and base your whole argument on it? I'm a Fuckin New Guy and I cut and paste sometimes. Sometimes a thing isn't ready to be crystallized, or is impractical to make modular without introducing too much complexity.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@yahoo.com |
|---|---|
| Date | 2014-06-26 22:49 -0700 |
| Message-ID | <c1d77ea1-0729-44c3-90ab-f5443f35be30@googlegroups.com> |
| In reply to | #31905 |
On Thursday, June 26, 2014 3:51:31 PM UTC-7, Roger Levy wrote: > > What this ["toolbelts" or "code in the back pocket"] means in practice, is that new programs are written by cut-and-pasting the source-code from old programs. For example, if an old program had an LLRB tree, then a new program that needed an LLRB tree would just get the source-code from the old program pasted into it, with the innards modified to make it work for the new data. > Did you read that Cut-and-Paste Is Bad somewhere and base your whole argument on it? Read??? I'm a writer, not a reader. > I'm a Fuckin New Guy and I cut and paste sometimes. Sometimes a thing isn't ready to be crystallized, or is impractical to make modular without introducing too much complexity. The FODs want you to cut-and-paste all of time, not just "sometimes." To some extent, ANS-Forth's lack of support for general-purpose reusable libraries is due to ignorance on the part of the leadership --- but to some extent this was done on purpose --- this is a FOD plot to force cut-and-paste programming on everybody, so the FODs can maintain their position at the top by restricting access to the old programs that new programs get remixed from, largely preventing FNGs from writing programs without the FODs permission. This FOD plot is what I've seen in machining in regard to CNC. When I see the same thing being done in Forth, I get riled up --- Forth is sacred ground --- but the FODs are pushing Forth down the same path that COBOL trod, for the same purpose (greed), to the same inglorious end in which nobody under the age of 40 will volunteer to be an FNG. Cut-and-paste programming is representative of the end of innovation, and a descent into purely backward-looking stagnation. FOD-stasis isn't just a problem for Forth --- it is a problem for civilization.
[toc] | [prev] | [next] | [standalone]
| From | Roger Levy <roger.levy@gmail.com> |
|---|---|
| Date | 2014-06-27 07:32 -0700 |
| Message-ID | <d24a42d7-dc4d-410f-9b3e-9e82d29f8434@googlegroups.com> |
| In reply to | #31924 |
> Read??? I'm a writer, not a reader. OK. He's a lover, not a fighter ;) > The FODs want you to cut-and-paste all of time, not just "sometimes." To some extent, ANS-Forth's lack of support for general-purpose reusable libraries is due to ignorance on the part of the leadership --- but to some extent this was done on purpose --- this is a FOD plot to force cut-and-paste programming on everybody, so the FODs can maintain their position at the top by restricting access to the old programs that new programs get remixed from, largely preventing FNGs from writing programs without the FODs permission. > > This FOD plot is what I've seen in machining in regard to CNC. When I see the same thing being done in Forth, I get riled up --- Forth is sacred ground --- but the FODs are pushing Forth down the same path that COBOL trod, for the same purpose (greed), to the same inglorious end in which nobody under the age of 40 will volunteer to be an FNG. > > Cut-and-paste programming is representative of the end of innovation, and a descent into purely backward-looking stagnation. FOD-stasis isn't just a problem for Forth --- it is a problem for civilization. That's a really interesting theory, and similar to thoughts I've had. It is a fact that I had to teach myself what the past generation learned through years of experience, or maybe by standing on the shoulders of their predecessors, and basically kept to themselves. Not just in Forth but in practically everything. I don't think it was conscious though. As I get older and spend more time around boomers in the professional field I see that a lot of them don't really know What's Going On and by all accounts just Did Their Best. And for some reason, that generation was not equipped to see too far beyond themselves until the final hour. Maybe all the previous generations didn't really think too far ahead beyond their immediate pressures. C'est la vie. Maybe the failure to pass on knowledge isn't even special to the boomers. Think of exactly how many people each generation write publications that survive into decades after their death, versus how many people were in that generation, and much of that knowledge gets misconstrued by how many people. Maybe it's that human beings just suck, or maybe it's western civilization and our over-reliance on technology, or maybe it's just overpopulation. The Internet is helping, I think.
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.forth
csiph-web