Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #45811 > unrolled thread
| Started by | Ron Aaron <rambamist@gmail.com> |
|---|---|
| First post | 2016-03-04 07:16 +0200 |
| Last post | 2016-03-26 12:06 +0000 |
| Articles | 20 on this page of 74 — 21 participants |
Back to article view | Back to comp.lang.forth
Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-04 07:16 +0200
Re: Best teaching methodology for Forths? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-03 23:21 -0800
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-04 12:37 -0800
Re: Best teaching methodology for Forths? november.nihal@gmail.com - 2016-03-04 03:25 -0800
Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-04 14:30 +0200
Re: Best teaching methodology for Forths? november.nihal@gmail.com - 2016-03-04 07:36 -0800
Re: Best teaching methodology for Forths? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-04 19:09 +0000
Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-05 18:53 +0200
Re: Best teaching methodology for Forths? Julian Fondren <julian.fondren@gmail.com> - 2016-03-04 11:11 -0800
Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-05 18:54 +0200
Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-05 13:59 -0500
Re: Best teaching methodology for Forths? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 00:56 +0000
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-05 17:16 -0800
Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-05 20:54 -0500
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-05 18:25 -0800
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-09 18:26 -0800
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-10 23:09 -0800
Re: Best teaching methodology for Forths? humptydumpty <ouatubi@gmail.com> - 2016-03-11 03:39 -0800
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-12 17:57 -0800
Re: Best teaching methodology for Forths? humptydumpty <ouatubi@gmail.com> - 2016-03-13 08:25 -0700
Re: Best teaching methodology for Forths? humptydumpty <ouatubi@gmail.com> - 2016-03-13 11:30 -0700
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-13 14:06 -0700
Re: Best teaching methodology for Forths? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-07 16:28 -0800
Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-07 19:39 -0500
Re: Best teaching methodology for Forths? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-08 22:13 +0000
Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-09 01:18 +0000
Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-08 20:41 -0500
Re: Best teaching methodology for Forths? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-10 22:33 -0800
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-10 23:17 -0800
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-13 14:41 -0700
Re: Best teaching methodology for Forths? Julian Fondren <julian.fondren@gmail.com> - 2016-03-13 17:26 -0700
Re: Best teaching methodology for Forths? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-13 21:46 -1000
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-14 08:12 -0700
Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-14 17:45 +0000
Re: Best teaching methodology for Forths? "Elizabeth D. Rather" <erather@forth.com> - 2016-03-14 14:11 -1000
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-15 01:13 -0700
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-14 08:55 -0700
Re: Best teaching methodology for Forths? Julian Fondren <ayrnieu@gmail.com> - 2016-03-15 03:16 -0700
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-16 16:13 -0700
Re: Best teaching methodology for Forths? "WJ" <w_a_x_man@yahoo.com> - 2016-03-26 22:11 +0000
Re: Best teaching methodology for Forths? "WJ" <w_a_x_man@yahoo.com> - 2016-03-26 22:15 +0000
Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-04 12:42 -0500
Re: Best teaching methodology for Forths? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-04 19:16 +0000
Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-04 15:22 -0500
Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-05 18:58 +0200
Re: Best teaching methodology for Forths? "HAA" <someone@microsoft.com> - 2016-03-09 10:07 +1100
Re: Best teaching methodology for Forths? IanYellowley <iany99@gmail.com> - 2016-03-04 13:57 -0800
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-04 15:07 -0800
Re: Best teaching methodology for Forths? stephen@mpeforth.com (Stephen Pelc) - 2016-03-05 11:22 +0000
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-05 15:10 -0800
Re: Best teaching methodology for Forths? Bernd Paysan <bernd.paysan@gmx.de> - 2016-03-06 00:05 +0000
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-05 17:06 -0800
Re: Best teaching methodology for Forths? rickman <gnuarm@gmail.com> - 2016-03-05 20:58 -0500
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-14 11:10 -0700
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-05 15:23 -0800
Re: Best teaching methodology for Forths? stephen@mpeforth.com (Stephen Pelc) - 2016-03-06 09:28 +0000
Re: Best teaching methodology for Forths? hughaguilar96@gmail.com - 2016-03-06 13:45 -0800
Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-05 18:59 +0200
Re: Best teaching methodology for Forths? Whammo <sidciavic@gmail.com> - 2016-03-08 19:47 -0800
Re: Best teaching methodology for Forths? Brad Eckert <hwfwguy@gmail.com> - 2016-03-23 16:19 -0700
Re: Best teaching methodology for Forths? Ron Aaron <rambamist@gmail.com> - 2016-03-24 07:29 +0200
Re: Best teaching methodology for Forths? Richard Owlett <rowlett@cloud85.net> - 2016-03-24 04:44 -0500
Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-24 12:47 +0000
Re: Best teaching methodology for Forths? Paul Rubin <no.email@nospam.invalid> - 2016-03-24 10:19 -0700
Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-25 00:54 +0000
Re: Best teaching methodology for Forths? Paul Rubin <no.email@nospam.invalid> - 2016-03-24 19:24 -0700
Re: Best teaching methodology for Forths? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-25 11:38 +0000
Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-25 12:42 +0000
Re: Best teaching methodology for Forths? Doug Hoffman <glidedog@gmail.com> - 2016-03-25 09:07 -0400
Re: Best teaching methodology for Forths? Julian Fondren <julian.fondren@gmail.com> - 2016-03-25 07:54 -0700
Re: Best teaching methodology for Forths? anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2016-03-25 14:29 +0000
Re: Best teaching methodology for Forths? Gerry Jackson <gerry@jackson9000.fsnet.co.uk> - 2016-03-25 21:17 +0000
Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-26 00:43 +0000
Re: Best teaching methodology for Forths? Albert van der Horst <albert@spenarnc.xs4all.nl> - 2016-03-26 12:06 +0000
Page 1 of 4 [1] 2 3 4 Next page →
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2016-03-04 07:16 +0200 |
| Subject | Best teaching methodology for Forths? |
| Message-ID | <nbb5il$n0l$1@dont-email.me> |
I've noticed that among the 8th user-base, there are some who "get it" immediately and within a week are writing real programs. There are others who, even after months, are barely able to write a functioning program. The first group consists not only of former Forthers, but also of complete novices. The second group seems to have far more long-term C/Java users. My question: what is the best way to teach people with disparate backgrounds how to program effectively in a Forth-type language? This is not an academic question: our distributor in India will be giving workshops, and we want to help the students there get comfortable and effective as quickly as possible. Thanks for any constructive suggestions!
[toc] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-03-03 23:21 -0800 |
| Message-ID | <y4adnY8FyJzmqkTLnZ2dnUU7-ePNnZ2d@supernews.com> |
| In reply to | #45811 |
On 3/3/16 9:16 PM, Ron Aaron wrote: > I've noticed that among the 8th user-base, there are some who "get it" > immediately and within a week are writing real programs. There are > others who, even after months, are barely able to write a functioning > program. > > The first group consists not only of former Forthers, but also of > complete novices. The second group seems to have far more long-term > C/Java users. > > My question: what is the best way to teach people with disparate > backgrounds how to program effectively in a Forth-type language? > > This is not an academic question: our distributor in India will be > giving workshops, and we want to help the students there get comfortable > and effective as quickly as possible. > > Thanks for any constructive suggestions! I have taught many people who have some programming experience to the level of being able to write useful code in a week, with a combination of lectures and the exercises in my Forth Application Techniques. Many people have also learned on their own with this book, but it requires actually working through the exercises; a course setting with a knowledgeable instructor is a tremendous help. IMO it's much harder to teach people who have no computer concepts (memory, bytes, execution, read/write, etc.) than those with basic programming in any language, although COBOL might be an inhibitor! 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@gmail.com |
|---|---|
| Date | 2016-03-04 12:37 -0800 |
| Message-ID | <6ef36f54-3b4f-4c68-a318-0bcce3819033@googlegroups.com> |
| In reply to | #45817 |
On Friday, March 4, 2016 at 12:21:33 AM UTC-7, Elizabeth D. Rather wrote: > I have taught many people who have some programming experience to the > level of being able to write useful code in a week, with a combination > of lectures and the exercises in my Forth Application Techniques. Many > people have also learned on their own with this book, but it requires > actually working through the exercises; a course setting with a > knowledgeable instructor is a tremendous help. The reason why people with programming experience (Java, C, etc.) "fail" to learn Forth is not that they are too dumb, but rather because they are too smart. They understand basic programming concepts and they quickly become frustrated when their "knowledgeable instructor" in Forth hits them with idiotic advice that anybody with a high-school education should be able to recognize as idiocy. They leave because they believe that all Forth programmers must be idiots and they don't want to associate with us anymore --- they didn't really fail --- it was their self-proclaimed "knowledgeable instructor" who failed. In this thread, https://groups.google.com/forum/#!topic/comp.lang.forth/CYR7FhjYMkg we have a typical example of idiotic advice: On Saturday, November 17, 2012 at 10:24:26 AM UTC-7, Elizabeth D. Rather wrote: > On 11/17/12 2:56 AM, Alex McDonald wrote: > > On Nov 17, 12:18 pm, Hugh Aguilar <hughaguila...@yahoo.com> wrote: > ... > >> I have multiple stacks, with each stack associated to a particular > >> data-type --- well, at least to a particular data-type size, as the > >> double-wide stack will be for both double-precision integers and > >> adr,len strings which are different data types but which both fit > >> nicely on the double-wide stack. The point of doing this is to reduce > >> the amount of stack-juggling that is done --- stack-juggling is a big > >> part of why ANS-Forth is widely considered to be unreadable --- it is > >> a major mess to have double-wide data intermingled with single-wide > >> data on the parameter stack. I will also support local variables of > >> course, but they won't be needed as a crutch to avoid stack-juggling > >> as is often true in ANS-Forth --- with the multiple stacks, Forth > >> purists who dislike locals will be able to write code without locals, > >> while yet avoiding all of that ugly stack-juggling that typically > >> plagues ANS-Forth. > > > > : foo s" abcd" over 1 ." the character " type ." is the first > > character of " type ; > > : hugh ??? ; > > > > Fill in the ??? please without introducing stack to stack moves. > > > > The addr-len parameters for a string are not an example of "double-wide" > data, they are a pair of single-cell items each of which has a meaning > and potential use independent of the fact that together they describe a > string. > > For example: > > S" Here is some text" PAD SWAP MOVE > > ...uses them individually but in a relevant way, as does Alex's example. Everybody knows that to be productive you need to use structs. It is a bad idea to always keep all the fields of a datum on the stack so they can be used individually. The datum should instead be abstracted as a struct, so the programmer can think of the whole struct as a single datum, and he doesn't have to have all those fields and all that internal information in front of him continually. It is just too confusing to have too much information on the stack at one time, and the result is that only super-simple programs can be written (like the examples in "Starting Forth") because as soon as the program grows to even a slightly more complicated level the programmer becomes confused by all these little individual pieces of data on the stack and he quickly becomes bogged down in bugs and fails to complete the program. Abstraction --- always a good idea! Information-hiding --- always a good idea! This is the key to writing complicated programs --- use general-purpose code-libraries to abstract away the complexity, so the complicated program becomes simple. Also, btw, any use of PAD is just stupid --- you don't understand the concept of reentrancy --- I was well aware of the problems with PAD when I was 18 years old and had only a high-school education in computer programming, but you are still teaching the novices PAD 30 years later, making the whole Forth community look stupid. You have admitted your grotesque ignorance regarding reentrancy several times already. You are an ignoramus, which is a person who is not just ignorant but who is proud of their ignorance. This is a typical quote from you: "Truly, I don't see the point of all this paranoia about reentrancy, particularly in systems without a multitasker. VARIABLE was *designed* for things that would be used in multiple definitions. I remember the horror of (*gasp*) global variables back in the 1960's in Fortran. But, frankly, in 30+ years of programming in Forth I never found them a problem. I think this is all about mythical dragons." This kind of quote is going to cause the typical Java or C programmer to guffaw with laughter --- you are making the entire Forth community a laughing stock. > IMO it's much harder to teach people who have no computer concepts > (memory, bytes, execution, read/write, etc.) than those with basic > programming in any language, although COBOL might be an inhibitor! Your only programming experience is in COBOL --- all of this idiotic advice that you spout comes straight from COBOL --- you never learned about abstraction and information-hiding in your COBOL programming days because COBOL doesn't support abstraction and information-hiding, and you still don't know about abstraction and information-hiding. You reek of COBOL in the same way that a pig reeks of mud --- COBOL is your natural environment. > Cheers, > Elizabeth Drunk again, are you? Cheers!
[toc] | [prev] | [next] | [standalone]
| From | november.nihal@gmail.com |
|---|---|
| Date | 2016-03-04 03:25 -0800 |
| Message-ID | <4b6e917e-5d30-41b4-9720-a88a62db72f2@googlegroups.com> |
| In reply to | #45811 |
Hi Ron, For me, I found "making up" small examples and trying to solve them helped me immensely. Something along the lines of Project Euler but more simpler. What I realised was : - that you must write something rather than nothing. - dont give up because it doesnt work - read other peoples code I am surprised that the second group failed because if they were long term users it indicates that have some aptitude to programming and concepts. NN NN
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2016-03-04 14:30 +0200 |
| Message-ID | <nbbuv7$3um$1@dont-email.me> |
| In reply to | #45822 |
Hi - On 04/03/2016 13:25, november.nihal@gmail.com wrote: > Hi Ron, > > For me, I found "making up" small examples and trying to solve them helped me immensely. Something along the lines of Project Euler but more simpler. Yes, I agree with that. > What I realised was : > - that you must write something rather than nothing. > - dont give up because it doesnt work > - read other peoples code And with that :) > I am surprised that the second group failed because if they were long term users it indicates that have some aptitude to programming and concepts. Yes, but the problem seems to be that long-term C-ish programmers really think in C concepts. They want to put everything in variables (rather than leveraging the stack), they want to write long words (instead of short phrases). So you end up with code that is very hard to debug, and they get (understandably) frustrated. This, even though 8th has a ton of sample code and a very good manual and a helpful forum. I'm actually rewriting the tutorial now, with a very strong emphasis on the proper Forthly-approach to coding.
[toc] | [prev] | [next] | [standalone]
| From | november.nihal@gmail.com |
|---|---|
| Date | 2016-03-04 07:36 -0800 |
| Message-ID | <36b3a61e-9ddf-4860-b7dd-f3426dcd390c@googlegroups.com> |
| In reply to | #45825 |
...
>
> > I am surprised that the second group failed because if they were long term users it indicates that have some aptitude to programming and concepts.
>
> Yes, but the problem seems to be that long-term C-ish programmers really
> think in C concepts. They want to put everything in variables (rather
> than leveraging the stack), they want to write long words (instead of
> short phrases). So you end up with code that is very hard to debug, and
> they get (understandably) frustrated.
>
> This, even though 8th has a ton of sample code and a very good manual
> and a helpful forum.
>
> I'm actually rewriting the tutorial now, with a very strong emphasis on
> the proper Forthly-approach to coding.
Perhaps you should meet them half way.
Let them use variable ( global / local ) and longer definitions if thats what works,
and
Insist on using comments ( stack comments ) and
If words dont work get the writer to debug them.
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-04 19:09 +0000 |
| Message-ID | <nbcmgt$t6o$1@dont-email.me> |
| In reply to | #45827 |
Am Fri, 04 Mar 2016 07:36:06 -0800 schrieb november.nihal: > Perhaps you should meet them half way. > > Let them use variable ( global / local ) and longer definitions if > thats what works, But actually that doesn't work. That's what they are used to, and what fails when they use Forth or a Forth-like language like 8th. Teaching people with "bad habits" that prevent them from becoming productive good habits is important, but may fail, because nobody wants to admit that they have bad habits. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2016-03-05 18:53 +0200 |
| Message-ID | <nbf2oh$f2f$1@dont-email.me> |
| In reply to | #45827 |
On 04/03/2016 17:36, november.nihal@gmail.com wrote: > Perhaps you should meet them half way. > > Let them use variable ( global / local ) and longer definitions if thats what works, It's not a question of "letting" them do one thing or the other. The issue is how to steer people to more productive methods of working.
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-03-04 11:11 -0800 |
| Message-ID | <b3ee3ec1-ae5b-4ac5-ac8e-ae1320a2dae3@googlegroups.com> |
| In reply to | #45825 |
On Friday, March 4, 2016 at 6:30:23 AM UTC-6, Ron Aaron wrote: > Yes, but the problem seems to be that long-term C-ish programmers really > think in C concepts. They want to put everything in variables (rather > than leveraging the stack), they want to write long words (instead of > short phrases). So you end up with code that is very hard to debug, and > they get (understandably) frustrated. Pedagogical techniques that I've never seen employed: 1. Here, have a bunch of variously broken programs. Make them work. 2. Here, have a bunch of the same program; they all do the same thing and they are all functional - they aren't buggy; they really do what they're supposed to do. One of them is written well and the rest are written in variously defective ways. Now take this list of feature requests and fulfill them for each variation of this program. Rather than say "you should use short definitions", you can show how much easier it is to troubleshoot and modify a program composed of short definitions. -- Julian
[toc] | [prev] | [next] | [standalone]
| From | Ron Aaron <rambamist@gmail.com> |
|---|---|
| Date | 2016-03-05 18:54 +0200 |
| Message-ID | <nbf2ql$f2f$2@dont-email.me> |
| In reply to | #45835 |
On 04/03/2016 21:11, Julian Fondren wrote: > Pedagogical techniques that I've never seen employed: > > 1. Here, have a bunch of variously broken programs. Make them work. That one's just plain cruel... > > 2. Here, have a bunch of the same program; they all do the same > thing and they are all functional - they aren't buggy; they really > do what they're supposed to do. One of them is written well and the > rest are written in variously defective ways. Now take this list of > feature requests and fulfill them for each variation of this > program. That's interesting... > > Rather than say "you should use short definitions", you can show how > much easier it is to troubleshoot and modify a program composed of > short definitions. Yes. I can see that working, thanks.
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-03-05 13:59 -0500 |
| Message-ID | <nbfa68$ca0$1@dont-email.me> |
| In reply to | #45857 |
On 3/5/2016 11:54 AM, Ron Aaron wrote: > > > On 04/03/2016 21:11, Julian Fondren wrote: > >> Pedagogical techniques that I've never seen employed: >> >> 1. Here, have a bunch of variously broken programs. Make them work. > > That one's just plain cruel... I don't agree. Coding is taught to avoid mistakes, but they happen anyway. Debugging is not really taught to programmers, they have to learn it by themselves. In school that was the hardest part of programming. It was not until I was in the field that I learned how to debug. Why not teach debugging techniques as well as give debugging exercises? In this case the lesson would be to learn the ways bad coding causes mistakes and is hard to debug. >> 2. Here, have a bunch of the same program; they all do the same >> thing and they are all functional - they aren't buggy; they really >> do what they're supposed to do. One of them is written well and the >> rest are written in variously defective ways. Now take this list of >> feature requests and fulfill them for each variation of this >> program. > > That's interesting... > >> >> Rather than say "you should use short definitions", you can show how >> much easier it is to troubleshoot and modify a program composed of >> short definitions. > > Yes. I can see that working, thanks. I think these are all good ideas. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-06 00:56 +0000 |
| Message-ID | <nbfv86$i9m$3@dont-email.me> |
| In reply to | #45860 |
Am Sat, 05 Mar 2016 13:59:42 -0500 schrieb rickman: >>> 1. Here, have a bunch of variously broken programs. Make them work. >> >> That one's just plain cruel... > > I don't agree. Coding is taught to avoid mistakes, but they happen > anyway. Debugging is not really taught to programmers, they have to > learn it by themselves. In school that was the hardest part of > programming. It was not until I was in the field that I learned how to > debug. Why not teach debugging techniques as well as give debugging > exercises? In this case the lesson would be to learn the ways bad > coding causes mistakes and is hard to debug. Yes, a very valid point. It's like if you learn boxing with a sandbag only, and then, in a real fight, you for the first time are confronted with someone who fights back. Extreme and Agile Programming do also teach their methodology on debugging (e.g. test-driven programming), and we should do that, too. -- Bernd Paysan "If you want it done right, you have to do it yourself" net2o ID: kQusJzA;7*?t=uy@X}1GWr!+0qqp_Cn176t4(dQ* http://bernd-paysan.de/
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-03-05 17:16 -0800 |
| Message-ID | <74ec127c-ea82-4f5a-a0e6-a83bd450c980@googlegroups.com> |
| In reply to | #45868 |
On Saturday, March 5, 2016 at 5:59:43 PM UTC-7, Bernd Paysan wrote: > Am Sat, 05 Mar 2016 13:59:42 -0500 schrieb rickman: > > Why not teach debugging techniques as well as give debugging > > exercises? In this case the lesson would be to learn the ways bad > > coding causes mistakes and is hard to debug. > > Yes, a very valid point. It's like if you learn boxing with a sandbag > only, and then, in a real fight, you for the first time are confronted > with someone who fights back. This is not the first time that Bernd Paysan has represented himself as an expert on boxing: On Saturday, August 1, 2015 at 3:22:29 PM UTC-7, Bernd Paysan wrote: > For some fun how important automating things is, watch some of the late 70s > Jackie Chan movies of the "Drunken Master" epoch. It's all about learning > Kung Fu. Kung Fu is such a stunning martial art, because the practicers > learn many complicated movements by heart. That takes an awful lot of time, > and it's the reason why a master in his 50s can easily beat a much stronger > learner in his 20s (and that's someone who already learns for 10 years or > more!). LOL Bernd knows nothing about the subject! And, btw, why is the grammar so bad in the above post? I think Bernd is drunk --- which definitely makes his reference to Jackie Chan's "Drunken Master" movie ironic!
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-03-05 20:54 -0500 |
| Message-ID | <nbg2e7$pbu$1@dont-email.me> |
| In reply to | #45870 |
On 3/5/2016 8:16 PM, hughaguilar96@gmail.com wrote: > On Saturday, March 5, 2016 at 5:59:43 PM UTC-7, Bernd Paysan wrote: >> Am Sat, 05 Mar 2016 13:59:42 -0500 schrieb rickman: >>> Why not teach debugging techniques as well as give debugging >>> exercises? In this case the lesson would be to learn the ways bad >>> coding causes mistakes and is hard to debug. >> >> Yes, a very valid point. It's like if you learn boxing with a sandbag >> only, and then, in a real fight, you for the first time are confronted >> with someone who fights back. > > This is not the first time that Bernd Paysan has represented himself as an expert on boxing: > > On Saturday, August 1, 2015 at 3:22:29 PM UTC-7, Bernd Paysan wrote: >> For some fun how important automating things is, watch some of the late 70s >> Jackie Chan movies of the "Drunken Master" epoch. It's all about learning >> Kung Fu. Kung Fu is such a stunning martial art, because the practicers >> learn many complicated movements by heart. That takes an awful lot of time, >> and it's the reason why a master in his 50s can easily beat a much stronger >> learner in his 20s (and that's someone who already learns for 10 years or >> more!). > > LOL > > Bernd knows nothing about the subject! > > And, btw, why is the grammar so bad in the above post? I think Bernd is drunk --- which definitely makes his reference to Jackie Chan's "Drunken Master" movie ironic! I see Hugh is back with us and in true form he is attacking anyone that catches his eye. I guess something bad happened in his life and he is here venting. Sometimes Hugh posts with meaningful insight but the last couple of days he has just been full of spite with nothing to offer. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-03-05 18:25 -0800 |
| Message-ID | <3f207cb4-f20b-4cef-95b8-9f7c18335864@googlegroups.com> |
| In reply to | #45874 |
This is what was said: On Saturday, March 5, 2016 at 6:06:50 PM UTC-7, hughag...@gmail.com wrote: > On Saturday, March 5, 2016 at 5:08:44 PM UTC-7, Bernd Paysan wrote: > > IMHO you should stop ranting about this mediocre design-by-committee- > > standard, and proceed with your straightForth standard, which certainly > > is not a fake grass-root movement, but a real one-man heterosexual hero > > show. > > John Passaniti disappeared a long time ago, but you continue to play the homo card (accusing me of being homophobic, which is the one argument that you are guaranteed to win against me). This would work a lot better if you found another homo to be your attack poodle. > > Alex McDonald was your attack poodle after John Passaniti left. He would say things to me like: > "You have a serious misunderstanding of pointers work." > "You really don't know how CREATE DOES> works." > etc. etc. > > You rewarded Alex McDonald for his loyalty to Forth-200x by allowing him to put his name on the quotations RfD, but then he disappeared before he got his slam-dunk and the RfD was approved. > > Now you don't have an attack poodle anymore. Don't worry though! One of the Forth-200x mailing-list brown-nosers will volunteer pretty soon --- being an attack-poodle is a big step up from being a common brown-noser. And we immediately have our first volunteer for the attack-poodle job: On Saturday, March 5, 2016 at 6:54:11 PM UTC-7, rickman wrote: > I see Hugh is back with us and in true form he is attacking anyone that > catches his eye. I guess something bad happened in his life and he is > here venting. Sometimes Hugh posts with meaningful insight but the last > couple of days he has just been full of spite with nothing to offer. I actually spent the last couple of days writing string-stack.4th --- I just get attacked for this stuff though --- nobody wants ANS-Forth code, but everybody wants to jump straight into being an ANS-Forth internet-expert without doing any programming.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-03-09 18:26 -0800 |
| Message-ID | <f18a42aa-4fc3-4303-93f6-fe11e916a164@googlegroups.com> |
| In reply to | #45878 |
On Saturday, March 5, 2016 at 7:25:18 PM UTC-7, hughag...@gmail.com wrote:
> This is what was said:
>
> On Saturday, March 5, 2016 at 6:06:50 PM UTC-7, hughag...@gmail.com wrote:
> > On Saturday, March 5, 2016 at 5:08:44 PM UTC-7, Bernd Paysan wrote:
> > > IMHO you should stop ranting about this mediocre design-by-committee-
> > > standard, and proceed with your straightForth standard, which certainly
> > > is not a fake grass-root movement, but a real one-man heterosexual hero
> > > show.
> >
> > John Passaniti disappeared a long time ago, but you continue to play the homo card (accusing me of being homophobic, which is the one argument that you are guaranteed to win against me). This would work a lot better if you found another homo to be your attack poodle.
> >
> > Alex McDonald was your attack poodle after John Passaniti left. He would say things to me like:
> > "You have a serious misunderstanding of pointers work."
> > "You really don't know how CREATE DOES> works."
> > etc. etc.
> >
> > You rewarded Alex McDonald for his loyalty to Forth-200x by allowing him to put his name on the quotations RfD, but then he disappeared before he got his slam-dunk and the RfD was approved.
> >
> > Now you don't have an attack poodle anymore. Don't worry though! One of the Forth-200x mailing-list brown-nosers will volunteer pretty soon --- being an attack-poodle is a big step up from being a common brown-noser.
>
> And we immediately have our first volunteer for the attack-poodle job:
>
> On Saturday, March 5, 2016 at 6:54:11 PM UTC-7, rickman wrote:
> > I see Hugh is back with us and in true form he is attacking anyone that
> > catches his eye. I guess something bad happened in his life and he is
> > here venting. Sometimes Hugh posts with meaningful insight but the last
> > couple of days he has just been full of spite with nothing to offer.
>
> I actually spent the last couple of days writing string-stack.4th --- I just get attacked for this stuff though --- nobody wants ANS-Forth code, but everybody wants to jump straight into being an ANS-Forth internet-expert without doing any programming.
Give Rickman a little pat on the head --- that is all the payment that a small yappy dog requires:
On Monday, March 7, 2016 at 5:28:48 PM UTC-7, Elizabeth D. Rather wrote:
> I agree with Rick...
If anybody is going to teach Forth, the first thing that needs to be taught is how to work around all of the restrictions in ANS-Forth. To write Forth code, the student needs to defeat Elizabeth Rather in every line of code! Here is an example:
: white? ( char -- flag )
bl <= ;
: nonwhite? ( char -- flag )
bl > ;
: darken ( adr len -- adr new-len ) \ remove all whitespace from string
2dup dup 1- { adr length suffix-length -- }
bounds ?do
0 0 do
J c@ nonwhite? if leave then
-1 +to length
suffix-length 0= if unloop leave then
J 1+ J suffix-length cmove
-1 +to suffix-length loop
-1 +to suffix-length loop
adr length ;
ANS-Forth doesn't have a +TO so you have to write your own (mine is in the novice package). This is trivial, but still, many students will struggle with this. Actually, it was a mistake for ANS-Forth to make locals use TO at all --- locals should have been made to provide the address, so @ ! +! etc. could be used to fetch and store --- TO is just ugly, and it is redundant because we already have @ ! +! etc. for accessing variables --- so getting used to locals at all will be a struggle for many students (I know it was for me).
ANS-Forth doesn't have { so you have to write your own (mine is in the novice package). This is non-trivial and the typical student will not be able to write this (Anton Ertl failed in his attempt, because he didn't initialize the locals after the | to zero, but instead initialized them to whatever happened to be in memory).
ANS-Forth lacks a BREAK so you can't use BEGIN WHILE REPEAT in many cases, but it is possible to use 0 0 DO LOOP and then use LEAVE to get out of the loop.
Pretty much every Forth function than anybody writes requires working around the failures of ANS-Forth --- this is what has to be taught to the students starting on day one.
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-03-10 23:09 -0800 |
| Message-ID | <6f696cff-0b72-4a5a-97f5-6d473a151a9d@googlegroups.com> |
| In reply to | #45952 |
On Wednesday, March 9, 2016 at 7:26:53 PM UTC-7, hughag...@gmail.com wrote:
> : darken ( adr len -- adr new-len ) \ remove all whitespace from string
> 2dup dup 1- { adr length suffix-length -- }
> bounds ?do
> 0 0 do
> J c@ nonwhite? if leave then
> -1 +to length
> suffix-length 0= if unloop leave then
> J 1+ J suffix-length cmove
> -1 +to suffix-length loop
> -1 +to suffix-length loop
> adr length ;
Here is a second version:
: darken ( adr len -- adr new-len )
over + \ -- base-adr limit
0 >r \ this is the sentinel
begin 2dup u< while
1- \ -- base-adr last-adr
dup c@ nonwhite? if dup c@ >r then
repeat
drop \ -- base-adr \ LAST-ADR = BASE-ADR at this time
0 over \ -- base-adr cnt adr
begin r> dup while \ -- base-adr cnt adr char
over c! \ -- base-adr cnt adr
swap 1+ swap 1+ repeat \ -- base-adr cnt adr 0
2drop ;
This second version may overflow the return-stack given a gigantic string --- the first version darkened the string in place.
The second version should be faster assuming that CMOVE is the speed-killer. On the other hand, given a large string (up to 32KB) with very little white-space in it, the second version might be slower due to data-cache thrashing.
I'm going with the second version in string-stack.4th --- for the most part, it should be faster --- strings of both natural language and (especially) programming language have a lot of white-space in them.
Anyway, my point is that students shouldn't have to be required to write this kind of code themselves --- general-purpose code should be provided in code-libraries --- students will become discouraged and will quit when they can't write easy programs (easy in any other language) without first delving into a lot of low-level programming that they aren't capable of yet (and, even if they are capable of it, don't have time or patience for).
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-03-11 03:39 -0800 |
| Message-ID | <0e218eee-18ca-458c-a743-b6e04874dbb6@googlegroups.com> |
| In reply to | #45973 |
On Friday, March 11, 2016 at 9:09:10 AM UTC+2, hughag...@gmail.com wrote:
> On Wednesday, March 9, 2016 at 7:26:53 PM UTC-7, hughag...@gmail.com wrote:
> > : darken ( adr len -- adr new-len ) \ remove all whitespace from string
> > 2dup dup 1- { adr length suffix-length -- }
> > bounds ?do
> > 0 0 do
> > J c@ nonwhite? if leave then
> > -1 +to length
> > suffix-length 0= if unloop leave then
> > J 1+ J suffix-length cmove
> > -1 +to suffix-length loop
> > -1 +to suffix-length loop
> > adr length ;
>
> Here is a second version:
>
> : darken ( adr len -- adr new-len )
> over + \ -- base-adr limit
> 0 >r \ this is the sentinel
> begin 2dup u< while
> 1- \ -- base-adr last-adr
> dup c@ nonwhite? if dup c@ >r then
> repeat
> drop \ -- base-adr \ LAST-ADR = BASE-ADR at this time
> 0 over \ -- base-adr cnt adr
> begin r> dup while \ -- base-adr cnt adr char
> over c! \ -- base-adr cnt adr
> swap 1+ swap 1+ repeat \ -- base-adr cnt adr 0
> 2drop ;
>
> This second version may overflow the return-stack given a gigantic string --- the first version darkened the string in place.
>
> The second version should be faster assuming that CMOVE is the speed-killer. On the other hand, given a large string (up to 32KB) with very little white-space in it, the second version might be slower due to data-cache thrashing.
>
> I'm going with the second version in string-stack.4th --- for the most part, it should be faster --- strings of both natural language and (especially) programming language have a lot of white-space in them.
>
> Anyway, my point is that students shouldn't have to be required to write this kind of code themselves --- general-purpose code should be provided in code-libraries --- students will become discouraged and will quit when they can't write easy programs (easy in any other language) without first delving into a lot of low-level programming that they aren't capable of yet (and, even if they are capable of it, don't have time or patience for).
Hi!
If using return stack, why not a recursive version?
: lastchar ( a u -- c ) 1- + c@ ;
: lastwhite? ( a u -- f ) lastchar bl <= ;
: -trail ( a u -- a u' )
2dup lastwhite? over AND
IF 1- recurse THEN
;
: darken ( a u -- a u' )
-trail dup 0 <= IF exit THEN
\ --- Chars producer:
2dup lastchar -rot
1- recurse ( ..c a 0 )
\ --- Chars consumer:
2dup 1+ 2>R
+ c! 2R>
;
Enjoying Forth,
humptydumpty
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-03-12 17:57 -0800 |
| Message-ID | <93184c91-a8b3-4f12-a845-c9267d66d05d@googlegroups.com> |
| In reply to | #45976 |
On Friday, March 11, 2016 at 4:39:43 AM UTC-7, humptydumpty wrote:
> On Friday, March 11, 2016 at 9:09:10 AM UTC+2, hughag...@gmail.com wrote:
> > On Wednesday, March 9, 2016 at 7:26:53 PM UTC-7, hughag...@gmail.com wrote:
> > > : darken ( adr len -- adr new-len ) \ remove all whitespace from string
> > > 2dup dup 1- { adr length suffix-length -- }
> > > bounds ?do
> > > 0 0 do
> > > J c@ nonwhite? if leave then
> > > -1 +to length
> > > suffix-length 0= if unloop leave then
> > > J 1+ J suffix-length cmove
> > > -1 +to suffix-length loop
> > > -1 +to suffix-length loop
> > > adr length ;
> >
> > Here is a second version:
> >
> > : darken ( adr len -- adr new-len )
> > over + \ -- base-adr limit
> > 0 >r \ this is the sentinel
> > begin 2dup u< while
> > 1- \ -- base-adr last-adr
> > dup c@ nonwhite? if dup c@ >r then
> > repeat
> > drop \ -- base-adr \ LAST-ADR = BASE-ADR at this time
> > 0 over \ -- base-adr cnt adr
> > begin r> dup while \ -- base-adr cnt adr char
> > over c! \ -- base-adr cnt adr
> > swap 1+ swap 1+ repeat \ -- base-adr cnt adr 0
> > 2drop ;
> >
> > This second version may overflow the return-stack given a gigantic string --- the first version darkened the string in place.
> >
> > The second version should be faster assuming that CMOVE is the speed-killer. On the other hand, given a large string (up to 32KB) with very little white-space in it, the second version might be slower due to data-cache thrashing.
> >
> > I'm going with the second version in string-stack.4th --- for the most part, it should be faster --- strings of both natural language and (especially) programming language have a lot of white-space in them.
> >
> > Anyway, my point is that students shouldn't have to be required to write this kind of code themselves --- general-purpose code should be provided in code-libraries --- students will become discouraged and will quit when they can't write easy programs (easy in any other language) without first delving into a lot of low-level programming that they aren't capable of yet (and, even if they are capable of it, don't have time or patience for).
>
> Hi!
> If using return stack, why not a recursive version?
>
> : lastchar ( a u -- c ) 1- + c@ ;
> : lastwhite? ( a u -- f ) lastchar bl <= ;
>
> : -trail ( a u -- a u' )
> 2dup lastwhite? over AND
> IF 1- recurse THEN
> ;
> : darken ( a u -- a u' )
> -trail dup 0 <= IF exit THEN
> \ --- Chars producer:
> 2dup lastchar -rot
> 1- recurse ( ..c a 0 )
> \ --- Chars consumer:
> 2dup 1+ 2>R
> + c! 2R>
> ;
>
> Enjoying Forth,
> humptydumpty
This is very elegant code. I like recursive functions! I will put it in my string-stack.4th as an example of cool Forth code (giving you credit, of course).
It will be commented out however, and I will stick with my function above that holds the chars on the return-stack. Your function uses too much memory as it fills up both the return-stack with return-addresses and the data-stack with chars, so there is going to be a lot of data-cache thrashing, plus it could overflow memory given a gigantic string and a limited-memory system.
The problem with my original function that did the work in place and didn't use extra memory, was that it was slow due to calling CMOVE which is a speed-killer. My function was also inefficient because it called CMOVE for every white char whereas it should call CMOVE only for every group of white chars --- it could be improved in this regard --- I'm tired of messing with this stuff though, and memory-conservation is only an issue on 16-bit computers which we don't use any more, so I'm not going to mess with DARKEN anymore.
Another thing --- this should really be called BLACKEN because it completely removes all white-space. I may later on write a DARKEN that removes all but one of every group of white chars. There are a lot of features that could be added in string-stack.4th, but I won't bother until it becomes clear that these features are needed.
[toc] | [prev] | [next] | [standalone]
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-03-13 08:25 -0700 |
| Message-ID | <52f4e8f7-3538-4abd-8f40-c375449ad6f3@googlegroups.com> |
| In reply to | #46026 |
On Sunday, March 13, 2016 at 3:57:50 AM UTC+2, hughag...@gmail.com wrote:
> On Friday, March 11, 2016 at 4:39:43 AM UTC-7, humptydumpty wrote:
> > On Friday, March 11, 2016 at 9:09:10 AM UTC+2, hughag...@gmail.com wrote:
> > > On Wednesday, March 9, 2016 at 7:26:53 PM UTC-7, hughag...@gmail.com wrote:
> > > > : darken ( adr len -- adr new-len ) \ remove all whitespace from string
> > > > 2dup dup 1- { adr length suffix-length -- }
> > > > bounds ?do
> > > > 0 0 do
> > > > J c@ nonwhite? if leave then
> > > > -1 +to length
> > > > suffix-length 0= if unloop leave then
> > > > J 1+ J suffix-length cmove
> > > > -1 +to suffix-length loop
> > > > -1 +to suffix-length loop
> > > > adr length ;
> > >
> > > Here is a second version:
> > >
> > > : darken ( adr len -- adr new-len )
> > > over + \ -- base-adr limit
> > > 0 >r \ this is the sentinel
> > > begin 2dup u< while
> > > 1- \ -- base-adr last-adr
> > > dup c@ nonwhite? if dup c@ >r then
> > > repeat
> > > drop \ -- base-adr \ LAST-ADR = BASE-ADR at this time
> > > 0 over \ -- base-adr cnt adr
> > > begin r> dup while \ -- base-adr cnt adr char
> > > over c! \ -- base-adr cnt adr
> > > swap 1+ swap 1+ repeat \ -- base-adr cnt adr 0
> > > 2drop ;
> > >
> > > This second version may overflow the return-stack given a gigantic string --- the first version darkened the string in place.
> > >
> > > The second version should be faster assuming that CMOVE is the speed-killer. On the other hand, given a large string (up to 32KB) with very little white-space in it, the second version might be slower due to data-cache thrashing.
> > >
> > > I'm going with the second version in string-stack.4th --- for the most part, it should be faster --- strings of both natural language and (especially) programming language have a lot of white-space in them.
> > >
> > > Anyway, my point is that students shouldn't have to be required to write this kind of code themselves --- general-purpose code should be provided in code-libraries --- students will become discouraged and will quit when they can't write easy programs (easy in any other language) without first delving into a lot of low-level programming that they aren't capable of yet (and, even if they are capable of it, don't have time or patience for).
> >
> > Hi!
> > If using return stack, why not a recursive version?
> >
> > : lastchar ( a u -- c ) 1- + c@ ;
> > : lastwhite? ( a u -- f ) lastchar bl <= ;
> >
> > : -trail ( a u -- a u' )
> > 2dup lastwhite? over AND
> > IF 1- recurse THEN
> > ;
> > : darken ( a u -- a u' )
> > -trail dup 0 <= IF exit THEN
> > \ --- Chars producer:
> > 2dup lastchar -rot
> > 1- recurse ( ..c a 0 )
> > \ --- Chars consumer:
> > 2dup 1+ 2>R
> > + c! 2R>
> > ;
> >
> > Enjoying Forth,
> > humptydumpty
>
> This is very elegant code. I like recursive functions! I will put it in my string-stack.4th as an example of cool Forth code (giving you credit, of course).
>
> It will be commented out however, and I will stick with my function above that holds the chars on the return-stack. Your function uses too much memory as it fills up both the return-stack with return-addresses and the data-stack with chars, so there is going to be a lot of data-cache thrashing, plus it could overflow memory given a gigantic string and a limited-memory system.
>
> The problem with my original function that did the work in place and didn't use extra memory, was that it was slow due to calling CMOVE which is a speed-killer. My function was also inefficient because it called CMOVE for every white char whereas it should call CMOVE only for every group of white chars --- it could be improved in this regard --- I'm tired of messing with this stuff though, and memory-conservation is only an issue on 16-bit computers which we don't use any more, so I'm not going to mess with DARKEN anymore.
>
> Another thing --- this should really be called BLACKEN because it completely removes all white-space. I may later on write a DARKEN that removes all but one of every group of white chars. There are a lot of features that could be added in string-stack.4th, but I won't bother until it becomes clear that these features are needed.
Hi!
Use it as you wish :) As an example I think is better to substitute
'0 <=' with '0='.
Yes, 'darken' is stacks hungry :) Somehow could be cured using a buffer
of fixed convenient size .
But what I think is cool - that 'darken' could be a prototype
for general unix-like filters for arrays of pointers to data. Something like:
\ Untested code. Beware!
\ Filter for Arrays of Pointers to Data. Unix filters like.
: th ( a u -- a' ) cells + ;
variable filterout' \ xt of effect ( a -- 0|-1 )
: (filter) ( a u -- a u' ;Filter array of pointers to data A U; 0 <= u' <= u )
BEGIN 2dup th @ filterout' @ execute over AND
WHILE 1-
REPEAT dup 0= IF exit THEN
2dup th @ -rot 1- recurse ( ..a' a 0 )
2dup 1+ 2>R
th ! 2R>
;
: filter ( a u xt -- a u' ) filterout' ! (filter) ;
' filter ALIAS |
\ USAGE: ( a u ) ' filter0 | ' filter1 | ... ' filterN | ( a u' )
Of course, (filter) could be a non-recursive version :)
Enjoying Forth,
humptydumpty
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web