Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #16411 > unrolled thread
| Started by | "Charles Richmond" <numerist@aquaporin4.com> |
|---|---|
| First post | 2012-10-17 16:56 -0500 |
| Last post | 2012-10-22 04:20 -0400 |
| Articles | 20 on this page of 89 — 23 participants |
Back to article view | Back to comp.lang.forth
FORTH Trouble--Please Show Me "Charles Richmond" <numerist@aquaporin4.com> - 2012-10-17 16:56 -0500
Re: FORTH Trouble--Please Show Me all2001@spambog.com (Wolfgang Allinger) - 2012-10-17 19:11 -0300
Re: FORTH Trouble--Please Show Me Mark Wills <forthfreak@gmail.com> - 2012-10-18 01:15 -0700
Re: FORTH Trouble--Please Show Me "Charles Richmond" <numerist@aquaporin4.com> - 2012-10-18 05:25 -0500
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-18 00:14 +0200
Re: FORTH Trouble--Please Show Me Spam@ControlQ.com - 2012-10-17 18:45 -0400
Re: FORTH Trouble--Please Show Me Anonymous <nobody@remailer.paranoici.org> - 2012-10-18 08:49 +0000
Re: FORTH Trouble--Please Show Me Spam@ControlQ.com - 2012-10-18 15:58 -0400
Re: FORTH Trouble--Please Show Me albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-18 21:53 +0000
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-19 18:39 -0700
Re: FORTH Trouble--Please Show Me Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-19 23:22 -0700
Re: FORTH Trouble--Please Show Me "Charles Richmond" <numerist@aquaporin4.com> - 2012-10-21 13:40 -0500
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-19 21:00 -1000
Re: FORTH Trouble--Please Show Me "A. K." <akk@nospam.org> - 2012-10-20 09:18 +0200
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-20 08:40 -1000
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-21 12:22 +0200
Re: FORTH Trouble--Please Show Me Doug Hoffman <glidedog@gmail.com> - 2012-10-21 08:46 -0400
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-18 21:08 +0200
Re: FORTH Trouble--Please Show Me Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-18 12:29 -0700
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-17 20:24 -0700
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-19 19:46 -0400
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-19 18:46 -0700
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-20 21:03 -0400
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-20 15:40 -1000
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-20 18:52 -0700
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-20 16:27 -1000
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-20 20:56 -0700
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-21 09:40 -0400
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-21 12:51 -0700
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-21 23:50 +0200
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-21 17:11 -0700
Re: FORTH Trouble--Please Show Me mhx@iae.nl - 2012-10-22 00:19 -0700
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 00:41 -0700
Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-22 09:31 -0500
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 08:13 -0700
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-22 21:40 +0200
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 13:14 -0700
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-22 10:41 -1000
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-22 23:21 +0200
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 14:27 -0700
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-22 14:16 -1000
Re: FORTH Trouble--Please Show Me Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2012-10-23 21:42 +0100
Re: FORTH Trouble--Please Show Me vandys@vsta.org - 2012-10-22 00:24 +0000
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 04:12 -0400
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 01:40 -0700
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 02:39 -0700
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 02:30 -0700
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 22:27 -0400
Re: FORTH Trouble--Please Show Me David Thompson <dave.thompson2@verizon.net> - 2012-11-04 22:18 -0500
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-11-05 15:35 +0100
Re: FORTH Trouble--Please Show Me humptydumpty <ouatubi@gmail.com> - 2012-10-22 12:22 -0700
Re: FORTH Trouble--Please Show Me Paul Rubin <no.email@nospam.invalid> - 2012-10-22 12:51 -0700
Re: FORTH Trouble--Please Show Me humptydumpty <ouatubi@gmail.com> - 2012-10-22 23:40 -0700
Re: FORTH Trouble--Please Show Me anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-23 12:50 +0000
Re: FORTH Trouble--Please Show Me humptydumpty <ouatubi@gmail.com> - 2012-10-24 09:13 -0700
Re: FORTH Trouble--Please Show Me anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-25 12:31 +0000
Re: FORTH Trouble--Please Show Me humptydumpty <ouatubi@gmail.com> - 2012-10-26 09:58 -0700
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-21 16:24 -0700
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-22 02:51 +0200
Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-21 19:55 -0500
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-22 03:02 +0200
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 03:50 -0400
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 01:03 -0700
Re: FORTH Trouble--Please Show Me stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-22 10:12 +0000
Re: FORTH Trouble--Please Show Me stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-22 10:08 +0000
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-22 18:06 +0200
Re: FORTH Trouble--Please Show Me mhx@iae.nl (Marcel Hendrix) - 2012-10-22 22:14 +0200
Re: FORTH Trouble--Please Show Me albert@spenarnc.xs4all.nl (Albert van der Horst) - 2012-10-23 00:50 +0000
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-23 03:43 +0200
Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-23 03:14 -0500
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 19:54 -0700
Re: FORTH Trouble--Please Show Me Mark Wills <markrobertwills@yahoo.co.uk> - 2012-10-22 22:59 -0700
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-24 09:23 -0700
Re: FORTH Trouble--Please Show Me stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-23 10:33 +0000
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-24 10:05 -0700
Re: FORTH Trouble--Please Show Me Doug Hoffman <glidedog@gmail.com> - 2012-10-24 14:56 -0400
Re: FORTH Trouble--Please Show Me anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-23 11:50 +0000
Re: FORTH Trouble--Please Show Me stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-23 14:39 +0000
Application Benchmarks (was: FORTH Trouble--Please Show Me) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-23 15:59 +0000
Re: Application Benchmarks (was: FORTH Trouble--Please Show Me) stephenXXX@mpeforth.com (Stephen Pelc) - 2012-10-24 14:33 +0000
Re: Application Benchmarks (was: FORTH Trouble--Please Show Me) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-10-25 14:19 +0000
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 03:56 -0400
Re: FORTH Trouble--Please Show Me "Elizabeth D. Rather" <erather@forth.com> - 2012-10-21 22:12 -1000
Re: FORTH Trouble--Please Show Me Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-10-22 02:51 -0700
Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-21 05:29 -0500
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-21 09:35 -0400
Re: FORTH Trouble--Please Show Me Bernd Paysan <bernd.paysan@gmx.de> - 2012-10-21 15:44 +0200
Re: FORTH Trouble--Please Show Me Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-10-21 18:43 -0500
Re: FORTH Trouble--Please Show Me "Rod Pemberton" <do_not_have@notemailnotz.cnm> - 2012-10-22 04:20 -0400
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-10-19 19:46 -0400 |
| Message-ID | <k5sogo$78k$1@speranza.aioe.org> |
| In reply to | #16422 |
"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message news:2017da18-ac49-4b0e-bec1-5ceffff9435e@pz10g2000pbb.googlegroups.com... ... > I recommend against implementing data structures as > a way to learn Forth. Lol! Classic. That should be your in your signature. RP
[toc] | [prev] | [next] | [standalone]
| From | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-10-19 18:46 -0700 |
| Message-ID | <7fa71346-ad58-4baf-bf96-a1e428b5bd58@p5g2000pbs.googlegroups.com> |
| In reply to | #16506 |
On Oct 19, 4:42 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> wrote: > "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message > > news:2017da18-ac49-4b0e-bec1-5ceffff9435e@pz10g2000pbb.googlegroups.com... > ... > > > I recommend against implementing data structures as > > a way to learn Forth. > > Lol! Classic. > > That should be your in your signature. > > RP > > I don't know why you laugh at this. Writing programs is the best way to learn. It is fun, you get a sense of accomplishment, and you learn the language. Implementing low-level data structures such as arrays is not fun but is quite boring, and you don't get any sense of accomplishment because you still haven't written a program that does something. I recommend writing a program that does something that you find interesting outside of the context of programming. Most people like games, so writing a game that you would enjoy playing is a good way to start. I did that with Forth when I was 18, and I'm doing it now with Scheme. What else would I do? To write a program more complicated than Hello-World however, you need to have basic data-structures such as records, arrays and lists already available.
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-10-20 21:03 -0400 |
| Message-ID | <k5vhel$b0k$1@speranza.aioe.org> |
| In reply to | #16510 |
"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message news:7fa71346-ad58-4baf-bf96-a1e428b5bd58@p5g2000pbs.googlegroups.com... > On Oct 19, 4:42 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> > wrote: > > "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message > > news:2017da18-ac49-4b0e-bec1-5ceffff9435e@pz10g2000pbb.googlegroups.com... ... > > > I recommend against implementing data structures as > > > a way to learn Forth. > > > > Lol! Classic. > > > > That should be your in your signature. > > I don't know why you laugh at this. Over the past six years, I can't even tell you how many Forth people posting here, and on other newsgroups I read also, constantly tout how good Forth is. But, all I see, without intending to incite flames, is a very weak language, as compared to many others, most notably C. Yet, none of these promoters of Forth ever see it's weakness, or perhaps are just unwilling to openly admit them. There are many areas of weakness in C, and I've discussed them with many people, in many different groups. You, without realizing it - perhaps, summarized, in one concise sentence, one of the many glaring defects of Forth: correctly implementing Forth data structures. I found it funny that you would attempt to learn a language without also learning how to implement data structures at the same time. The two go hand in hand. Without data structures, a language is just a bunch of do-nothing loops and if's. You basically said you should learn Forth without learning a critical component of it! Now, having read many of your posts, I took your own apparent revulsion to implementing data structures in Forth to be a direct response of you developing them for your novice and slide rule Forth packages. Am I mistaken? Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-10-20 15:40 -1000 |
| Message-ID | <oJqdnXP1QMbkzx7NnZ2dnUVZ_r2dnZ2d@supernews.com> |
| In reply to | #16526 |
On 10/20/12 3:03 PM, Rod Pemberton wrote: ... >>>> I recommend against implementing data structures as >>>> a way to learn Forth. >>> >>> Lol! Classic. >>> >>> That should be your in your signature. >> >> I don't know why you laugh at this. > > > Over the past six years, I can't even tell you how many Forth people posting > here, and on other newsgroups I read also, constantly tout how good Forth > is. But, all I see, without intending to incite flames, is a very weak > language, as compared to many others, most notably C. Yet, none of these > promoters of Forth ever see it's weakness, or perhaps are just unwilling to > openly admit them. There are many areas of weakness in C, and I've > discussed them with many people, in many different groups. You, without > realizing it - perhaps, summarized, in one concise sentence, one of the many > glaring defects of Forth: correctly implementing Forth data structures. You're making the mistake of listening to Hugh, rather than the horselaugh that follows his absurd assertion. And you're making the mistake of judging Forth based on a feature list, without actually making the effort to learn how it's used in applications. How can the ability to define any kind of data structure you want, with exactly the compile-time and run-time behavior you need, be a weakness? It's one of the most powerful features I've seen in any language. 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 | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-20 18:52 -0700 |
| Message-ID | <7xmwzgh9qw.fsf@ruckus.brouhaha.com> |
| In reply to | #16526 |
"Rod Pemberton" <do_not_have@notemailnotz.cnm> writes: > Without data structures, a language is just a bunch of do-nothing > loops and if's. You basically said you should learn Forth without learning > a critical component of it! Especially in the embedded regime, a heck of a lot of real-world programs don't have any complex algorithms or data structures. There's just some variables and maybe a few arrays, plus the stacks for intermediate values and control, plus a bunch of special case tests and i/o for the application at hand. Even numerical computation (numerical linear algebra or signal processing, say), which does use fancy algorithms, tends to still not use advanced data structures beyond the aforesaid variables and arrays. Language processing and compilers do use fancy data structures, and Forth newbies who get interested in implementing Forth themselves, often get advised not to do it. That is probably not a coincidence. Implementing Forth in Forth typically uses data structures that are within Forth's capabilities, but not completely within its comfort zone. And those data structure (linear ALLOT area and linked wordlists) are themselves unusually simple compared to what more usual compiler writers are used to.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-10-20 16:27 -1000 |
| Message-ID | <n9mdnRcVsJjkwB7NnZ2dnUVZ_vKdnZ2d@supernews.com> |
| In reply to | #16528 |
On 10/20/12 3:52 PM, Paul Rubin wrote: > "Rod Pemberton" <do_not_have@notemailnotz.cnm> writes: >> Without data structures, a language is just a bunch of do-nothing >> loops and if's. You basically said you should learn Forth without learning >> a critical component of it! > > Especially in the embedded regime, a heck of a lot of real-world > programs don't have any complex algorithms or data structures. There's > just some variables and maybe a few arrays, plus the stacks for > intermediate values and control, plus a bunch of special case tests and > i/o for the application at hand. Even numerical computation (numerical > linear algebra or signal processing, say), which does use fancy > algorithms, tends to still not use advanced data structures beyond the > aforesaid variables and arrays. > This is true, but Forth's ability to define application-specific data types is still valuable in embedded systems. Examples I've seen include named "objects" that are actually data ports (or even selected bits on a data port) with implicit reads or writes when accessed; circular buffers for high-speed data acquisition, and a circular list of polynomial coefficients that returns the next one when referenced. The ability to define custom data types easily is one of Forth's most powerful (and unique) features. But it's also something that's easy for beginners to learn, and I think it would be a massive disservice to advise someone to forgo learning it! 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 | Hugh Aguilar <hughaguilar96@yahoo.com> |
|---|---|
| Date | 2012-10-20 20:56 -0700 |
| Message-ID | <717bab9e-8733-4399-a881-bd6766ba6ef2@i2g2000pbi.googlegroups.com> |
| In reply to | #16526 |
On Oct 20, 6:00 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> wrote: > "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message > > news:7fa71346-ad58-4baf-bf96-a1e428b5bd58@p5g2000pbs.googlegroups.com...> On Oct 19, 4:42 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> > > wrote: > > > "Hugh Aguilar" <hughaguila...@yahoo.com> wrote in message > > news:2017da18-ac49-4b0e-bec1-5ceffff9435e@pz10g2000pbb.googlegroups.com... > ... > > > > > I recommend against implementing data structures as > > > > a way to learn Forth. > > > > Lol! Classic. > > > > That should be your in your signature. > > > I don't know why you laugh at this. > > Over the past six years, I can't even tell you how many Forth people posting > here, and on other newsgroups I read also, constantly tout how good Forth > is. But, all I see, without intending to incite flames, is a very weak > language, as compared to many others, most notably C. Yet, none of these > promoters of Forth ever see it's weakness, or perhaps are just unwilling to > openly admit them. There are many areas of weakness in C, and I've > discussed them with many people, in many different groups. You, without > realizing it - perhaps, summarized, in one concise sentence, one of the many > glaring defects of Forth: correctly implementing Forth data structures. I > found it funny that you would attempt to learn a language without also > learning how to implement data structures at the same time. The two go hand > in hand. Without data structures, a language is just a bunch of do-nothing > loops and if's. You basically said you should learn Forth without learning > a critical component of it! Now, having read many of your posts, I took > your own apparent revulsion to implementing data structures in Forth to be a > direct response of you developing them for your novice and slide rule Forth > packages. Am I mistaken? > > Rod Pemberton I wouldn't say that I have a "revulsion" for implementing data structures from my experience implementing them in the novice package (the slide-rule program was a demonstration of the novice package, and I didn't implement any data structures in there) --- implementing data structures isn't particularly difficult. I'm saying that novices shouldn't be required to implement data structures before they can write their first program. They should have basic stuff such as records, arrays and linked-lists available already. This is necessary for even the simplest program. Novices need to get their feet wet writing programs. They need the sense of accomplishment that comes from writing a program that works and does something. What it does can be fairly simple such as converting data from one format to another. It can even do something silly like play Pong on a text screen (use the asterisk as the ball and the square brackets as the paddle). It has to do something though. Implementing arrays or whatever is just boring, because when you are done you can't claim to have yet written a program. I remember in MS-DOS days that we had QBasic that lacked records. The typical solution was to define multiple arrays, each of which contained one field of the record. After you calculate your index it would be used in the appropriate array to get whatever field you need. PolyForth also lacked records. It is actually easy to implement records, but "Starting Forth" was so novice-level that it didn't even provide this "advanced" information. The result is that people tended to consider Forth in the same category as QBasic, which is to say that they were toy languages unsuitable for writing real programs. Also, people would sometimes carry over their QBasic techniques, such as the several arrays representing a record, to their Forth programming. This looked ridiculous! They didn't know any better though. I've read Elizabeth Rather's books, the handbook and the application guide (which cost me about $75), and they were extremely light on useful information. There is nothing in there explaining the implementation of even rudimentary data structures. People just figure this stuff out on their own eventually, but they mostly screw it up. My novice package provides these data structures in a way that is robust and efficient --- most people just implement this stuff off the cuff when they need it and produce something that can't really be reused in another program, so every program has a different ad hoc implementation of arrays or linked lists or whatever, and this lack of consistency is largely what gives Forth a reputation for being unreadable. I agree that Forth has weaknesses. I don't think that C is any better though; C is worse. Forth is pretty lame compared to Scheme or Lisp however. In my novice package I implemented linked lists. I provided EACH that would take the xt of a function (what I call a "toucher" in the documentation) and execute it for every node in the list. This is much better than manually writing out a loop every time that you need to traverse a list. In my slide-rule program there are over 30 uses of EACH --- you don't want to write essentially the same code that many times. In Scheme this kind of thing is common. In Forth, people just write all of their code manually over and over again. In Forth something like EACH is difficult to implement because ANS-Forth lacks closures. Both Forth and C are seriously hamstrung by their lack of support for closures. Straight Forth will have closures though --- this will be its strong point. You can't use Scheme on a micro- controller, as a lot of Scheme features such as dynamic OOP and GC are inappropriate. With Straight Forth however, you will get closures and so you can program in a Scheme-like way --- but still use a language appropriate for micro-controllers. I recommend that Forth be used for micro-controller programming, Scheme or Lisp be used for desktop-computer application programming, and C be phased out. "When C++ is your hammer, every problem looks like your thumb." (this is some guy's tag-line on the Racket mailing list)
[toc] | [prev] | [next] | [standalone]
| From | "Rod Pemberton" <do_not_have@notemailnotz.cnm> |
|---|---|
| Date | 2012-10-21 09:40 -0400 |
| Message-ID | <k60tp6$64v$1@speranza.aioe.org> |
| In reply to | #16532 |
"Hugh Aguilar" <hughaguilar96@yahoo.com> wrote in message news:717bab9e-8733-4399-a881-bd6766ba6ef2@i2g2000pbi.googlegroups.com... > On Oct 20, 6:00 pm, "Rod Pemberton" <do_not_h...@notemailnotz.cnm> > wrote: ... > [Novices] should have basic stuff such as records, > arrays and linked-lists available already. C has structs and arrays. That's what's needed. > This is necessary for even the simplest program. As C proves - it's missing them too - there is minimal need for linked-lists. Are they needed from time to time? Yes. So are complex numbers, but C didn't support those for a long time either. > I remember in MS-DOS days that we had QBasic that lacked records. > The typical solution was to define multiple arrays, each of which > contained one field of the record. After you calculate your index it > would be used in the appropriate array to get whatever field you need. Isn't that the way Forth _still_ does it? See CFA, LFA, PFA, or >BODY, >NAME, >LINK, etc. They all define offsets from the start of a "struct". I think I may have mentioned this in a prior conversation. The only C compiler I'm aware of that requires the user to use offsets to implement struct's is an old and very primitive compiler known as SmallC. > I agree that Forth has weaknesses. I don't think that C is any better > though; C is worse. Yet, nearly every language in existence uses or has used C as it's backend. Doesn't that prove C's effectiveness? > In Forth something like EACH is difficult to implement because > ANS-Forth lacks closures. Both Forth and C are seriously hamstrung > by their lack of support for closures. "Closures" seems to be the one "magic" feature that everyone seems to think is missing from their favorite language. What's so special about closures? What does C need closures for? What does Forth ... ? I may have asked you that previously. I know I've asked others on comp.lang.misc and elsewhere. I doubt I've gotten a satisfactory answer so far. I may need to see sample code to grasp the issue ... C has been used to implement nearly all, if not all, of the languages on Wikipedia's "closure" page that have closures or closure like structures. I know I've been over _this_ previously on c.l.f. ... > [...] and C be phased out. Lol! (I just don't foresee that happening any time soon.) C still very effectively captures the "essence" of a modern microprocessor. Rod Pemberton
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-21 12:51 -0700 |
| Message-ID | <7x3917hacl.fsf@ruckus.brouhaha.com> |
| In reply to | #16540 |
"Rod Pemberton" <do_not_have@notemailnotz.cnm> writes:
> C has structs and arrays. That's what's needed.
Well, C doesn't really have arrays ;-).
> "Closures" seems to be the one "magic" feature that everyone seems to think
> is missing from their favorite language. What's so special about closures?
They're not magic. You can do similar things with OOP or structs
containing function pointers and data, but closures avoid a lot of
syntactic clutter and bureaucracy compared to that. Example in Python:
def square(x):
return x*x
def derivative(f, h): # approximate numerical derivative
def df(x):
return (f(x+h) - f(x)) / h
return df
print square(3) # prints 9
print derivative(square,0.0001)(3) # prints approximately 6
You could write something like "derivative" in C with function pointers,
but it would be much messier.
> C has been used to implement nearly all, if not all, of the languages on
> Wikipedia's "closure" page that have closures or closure like structures. I
> know I've been over _this_ previously on c.l.f. ...
It's just the usual situation of using a simpler tool to implement a
more advanced one. Jet engines are made using screwdrivers, not the
other way around. C is the screwdriver in that picture.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-10-21 23:50 +0200 |
| Message-ID | <87851214938435@frunobulax.edu> |
| In reply to | #16545 |
Paul Rubin <no.email@nospam.invalid> writes Re: FORTH Trouble--Please Show Me [..] > Example in Python: > > def square(x): > return x*x > > def derivative(f, h): # approximate numerical derivative > def df(x): > return (f(x+h) - f(x)) / h > return df > > print square(3) # prints 9 > print derivative(square,0.0001)(3) # prints approximately 6 > You could write something like "derivative" in C with function pointers, > but it would be much messier. [..] I doubt the much in "much messier." -marcel -- ------------------- ANEW -derivative : eval ( ? xt -- ? ) ( F: ? -- ? ) EXECUTE ; : derivative ( xt -- ) ( F: x h -- d ) LOCAL f FLOCALS| h x | x h F+ f eval x f eval F- h F/ ; CR 3e FSQR F. \ prints 9 CR ' FSQR 3e 1e-4 derivative F. \ prints approximately 6 \ FORTH> in idata/derivative \ 9.000000 \ 6.000100 ok
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-21 17:11 -0700 |
| Message-ID | <7xzk3fmkm2.fsf@ruckus.brouhaha.com> |
| In reply to | #16546 |
mhx@iae.nl (Marcel Hendrix) writes:
> ANEW -derivative
>
> : eval ( ? xt -- ? ) ( F: ? -- ? ) EXECUTE ;
>
> : derivative ( xt -- ) ( F: x h -- d )
> LOCAL f FLOCALS| h x |
> x h F+ f eval x f eval F- h F/ ;
>
> CR 3e FSQR F. \ prints 9
> CR ' FSQR 3e 1e-4 derivative F. \ prints approximately 6
If I understand this, it doesn't actually create a closure. Rather, it
passes a function as an arg to derivative that gets called during the
call to derivative, so if you want to compute two derivatives you have
to call "derivative" twice. Maybe I'm wrong. Can you do this slightly
modified example? Change
print square(3) # prints 9
print derivative(square,0.0001)(3) # prints approximately 6
to:
print square(3) # prints 9
d = derivative(square, 0.00001)
print d(3) # prints approximately 6
print d(4) # prints approximately 8
I may not have made it clear enough earlier: the thing coming back from
"derivative" is a value that you can (for example) save in the variable
"d" (like above). That value is the closure.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl |
|---|---|
| Date | 2012-10-22 00:19 -0700 |
| Message-ID | <b48cc76f-803e-4c33-a799-3e365559fbd2@googlegroups.com> |
| In reply to | #16549 |
On Monday, October 22, 2012 2:11:17 AM UTC+2, Paul Rubin wrote: > Can you do this slightly modified example? [..] -- first version : derive ( xt -- ) ( F: x h -- d ) LOCAL f FLOCALS| h x | x h F+ f EXECUTE x f EXECUTE F- h F/ ; CR 3e FSQR F. .( \ prints 9 ) CR ' FSQR 3e 1e-4 derive F. .( \ prints approximately 6 ) -- second version : derivative ( xt1 -- xt2 ) ( F: h -- ) \ "name" CREATE F, , DOES> F@+ @ derive ; ' FSQR 1e-4 derivative d CR 3e FSQR F. .( \ prints 9 ) CR 3e d F. .( \ prints approximately 6 ) CR 4e d F. .( \ prints approximately 8 ) -marcel
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-22 00:41 -0700 |
| Message-ID | <7xk3ujx8br.fsf@ruckus.brouhaha.com> |
| In reply to | #16557 |
mhx@iae.nl writes: > -- second version > : derivative ( xt1 -- xt2 ) ( F: h -- ) \ "name" > CREATE F, , DOES> F@+ @ derive ; > > ' FSQR 1e-4 derivative d > CR 3e FSQR F. .( \ prints 9 ) > CR 3e d F. .( \ prints approximately 6 ) > CR 4e d F. .( \ prints approximately 8 ) This is better, though it allocates permanent space in the dictionary rather than returning a temporary value (the Python program used a variable but the Forth equivalent would be to return a value on the stack). Of course Python uses something like ALLOCATE under the hood, and automatically reclaims the space once the value has no live references left, and you could do something similar with Anton's garbage collector for Gforth. Anyway I'll accept that your second version is reasonably close, and only somewhat messy.
[toc] | [prev] | [next] | [standalone]
| From | Andrew Haley <andrew29@littlepinkcloud.invalid> |
|---|---|
| Date | 2012-10-22 09:31 -0500 |
| Message-ID | <QPmdnYOEfOEixRjNnZ2dnUVZ8tednZ2d@supernews.com> |
| In reply to | #16559 |
Paul Rubin <no.email@nospam.invalid> wrote: > mhx@iae.nl writes: >> -- second version >> : derivative ( xt1 -- xt2 ) ( F: h -- ) \ "name" >> CREATE F, , DOES> F@+ @ derive ; >> >> ' FSQR 1e-4 derivative d >> CR 3e FSQR F. .( \ prints 9 ) >> CR 3e d F. .( \ prints approximately 6 ) >> CR 4e d F. .( \ prints approximately 8 ) > > This is better, though it allocates permanent space in the dictionary > rather than returning a temporary value (the Python program used a > variable but the Forth equivalent would be to return a value on the > stack). Yeah, but that's just Forth: Forth generally prefers static allocation to dynamic allocation. A dynamic version would surely have been possible, but in the absence of GC its use would have been a bit painful. Andrew.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-22 08:13 -0700 |
| Message-ID | <7x1ugqmtff.fsf@ruckus.brouhaha.com> |
| In reply to | #16576 |
Andrew Haley <andrew29@littlepinkcloud.invalid> writes: > Yeah, but that's just Forth: Forth generally prefers static allocation > to dynamic allocation. A dynamic version would surely have been > possible, but in the absence of GC its use would have been a bit > painful. Right, the same could be said for C. The conclusion is that using this style in either of those languages probably more trouble than it's worth.
[toc] | [prev] | [next] | [standalone]
| From | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-10-22 21:40 +0200 |
| Message-ID | <82631413938435@frunobulax.edu> |
| In reply to | #16559 |
Paul Rubin <no.email@nospam.invalid> writes Re: FORTH Trouble--Please Show Me > mhx@iae.nl writes: >> -- second version >> : derivative ( xt1 -- xt2 ) ( F: h -- ) \ "name" >> CREATE F, , DOES> F@+ @ derive ; >> >> ' FSQR 1e-4 derivative d >> CR 3e FSQR F. .( \ prints 9 ) >> CR 3e d F. .( \ prints approximately 6 ) >> CR 4e d F. .( \ prints approximately 8 ) > This is better, though it allocates permanent space in the dictionary > rather than returning a temporary value (the Python program used a > variable but the Forth equivalent would be to return a value on the > stack). Of course Python uses something like ALLOCATE under the hood, > and automatically reclaims the space once the value has no live > references left, and you could do something similar with Anton's garbage > collector for Gforth. Anyway I'll accept that your second version is > reasonably close, and only somewhat messy. In a Forth context (this is CLF) it is absolutely no limitation that dictionary space is allotted. This is because "derivative" is executed only once [here *]. The data space allotted by F, and , is insignificant with respect to d's header space. As Forth is an interpreter (as is Python!), the space taken by words like d can never be reclaimed: at any time the user may type "d". Only the interpreter's exit (i.e. BYE) can trigger the return of ALLOTted space. If use of 'd-type' words is such that they can't be reached by the interpreter anymore, this can only mean that MARKER has been executed. In that case all space is (automatically) reclaimed. Forth words can execute MARKER words. I admit that I am resisting going along with your silent demand to show a extremely messy and complicated bastard closure in Forth :-) A basic idea in Forth is to not building in hooks that may never be used [*]. Believe me, the better your specification for a useful piece of code that absolutely needs closures, the happier both of us will be. And yes, I really think that the Forth interpreter should be kept in all Forth programs, and that all Forth programs should be built from source. -marcel
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-22 13:14 -0700 |
| Message-ID | <7xmwzes1qo.fsf@ruckus.brouhaha.com> |
| In reply to | #16587 |
mhx@iae.nl (Marcel Hendrix) writes: > As Forth is an interpreter (as is Python!), the space taken by words > like d can never be reclaimed: at any time the user may type "d". Only > the interpreter's exit (i.e. BYE) can trigger the return of ALLOTted > space. Well, in the Python version, d (assuming it was inside some function definition) was the equivalent of a local, so I'd expect it to get cleaned up when the function returned. > Believe me, the better your specification for a useful piece of code that > absolutely needs closures, the happier both of us will be. I think I said up front, there is no code that absolutely needs closures. They just make things easier some of the time, so you can complete your task faster. It comes down to this: http://people.cs.umass.edu/~yannis/law.html a version of Moore's law, that claims programmer productivity doubles every 6 years. Improvements in languages and software understanding surely have a lot to do with that. Those of us who have been programming for a while should be asking ourselves, "has my productivity doubled in the last 6 years? And what am I going to do to double it again in the next 6 years?" Staying on top of current tools and techniques is an important component.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2012-10-22 10:41 -1000 |
| Message-ID | <58SdnXFY-5roMhjNnZ2dnUVZ_jednZ2d@supernews.com> |
| In reply to | #16593 |
On 10/22/12 10:14 AM, Paul Rubin wrote: > mhx@iae.nl (Marcel Hendrix) writes: >> As Forth is an interpreter (as is Python!), the space taken by words >> like d can never be reclaimed: at any time the user may type "d". Only >> the interpreter's exit (i.e. BYE) can trigger the return of ALLOTted >> space. > > Well, in the Python version, d (assuming it was inside some function > definition) was the equivalent of a local, so I'd expect it to get > cleaned up when the function returned. A better implementation would be to put those values in a reusable space such as PAD. 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 | mhx@iae.nl (Marcel Hendrix) |
|---|---|
| Date | 2012-10-22 23:21 +0200 |
| Message-ID | <79141213938435@frunobulax.edu> |
| In reply to | #16594 |
"Elizabeth D. Rather" <erather@forth.com> writes Re: FORTH Trouble--Please Show Me > On 10/22/12 10:14 AM, Paul Rubin wrote: >> mhx@iae.nl (Marcel Hendrix) writes: >>> As Forth is an interpreter (as is Python!), the space taken by words >>> like d can never be reclaimed: at any time the user may type "d". Only >>> the interpreter's exit (i.e. BYE) can trigger the return of ALLOTted >>> space. >> >> Well, in the Python version, d (assuming it was inside some function >> definition) was the equivalent of a local, so I'd expect it to get >> cleaned up when the function returned. > A better implementation would be to put those values in a reusable space > such as PAD. : derive ( xt -- ) ( F: x h -- d ) LOCAL f FLOCALS| h x | x h F+ f EXECUTE x f EXECUTE F- h F/ ; : derivative ( xt1 -- xt2 ) ( F: h -- ) \ "name" CREATE F, , DOES> F@+ @ derive ; : C[ S" marker -once" EVALUATE ; : ]C S" -once" EVALUATE ; C[ CR 3e FSQR F. .( \ prints 9 ) CR ' FSQR 3e 1e-4 derive F. .( \ prints approximately 6 ) ' FSQR 1e-4 derivative d CR 3e FSQR F. .( \ prints 9 ) CR 3e d F. .( \ prints approximately 6 ) CR 4e d F. .( \ prints approximately 8 ) ' FSIN 1e-4 derivative e ' e 1e-4 derivative f CR PI/2 e F. .( \ prints dsin[pi/2] = cos[pi/2] ) CR PI/2 f F. .( \ prints ddsin[pi/2] = -sin[pi/2] ) : .tt 0e #4 0 do FDUP e F. PI/2 F+ LOOP FDROP ; CR .tt .( cosine in a loop ) ]C -- output FORTH> in 9.000000 \ prints 9 6.000100 \ prints approximately 6 9.000000 \ prints 9 6.000100 \ prints approximately 6 8.000100 \ prints approximately 8 -0.000050 \ prints dsin[pi/2] = cos[pi/2] -1.000000 \ prints ddsin[pi/2] = -sin[pi/2] 1.000000 -0.000050 -1.000000 0.000050 ok FORTH> words ]C C[ derivative derive -derivative
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2012-10-22 14:27 -0700 |
| Message-ID | <7xy5iy9ozt.fsf@ruckus.brouhaha.com> |
| In reply to | #16594 |
"Elizabeth D. Rather" <erather@forth.com> writes: > A better implementation would be to put those values in a reusable > space such as PAD. Then they could get overwritten by something else while still in use. Really, we're talking about a language feature that just doesn't fit into the Forth way of doing things. The most sensible approximation is probably with OOP and whatever methods Forthers normally use to reclaim storage from dead objects.
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | comp.lang.forth
csiph-web