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 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
| From | humptydumpty <ouatubi@gmail.com> |
|---|---|
| Date | 2016-03-13 11:30 -0700 |
| Message-ID | <e2166ce0-4eb4-4402-b290-eba1fa5050c6@googlegroups.com> |
| In reply to | #46035 |
On Sunday, March 13, 2016 at 5:25:28 PM UTC+2, humptydumpty wrote:
> 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
Oops, off by one! Fixed version:
\ Untested code. Beware!
\ Filter for Arrays of Pointers to Data. Unix filters like.
: th ( a u -- a' ) cells + ;
: last ( a u -- n ) 1- th @ ;
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 last filterout' @ execute over AND
WHILE 1-
REPEAT dup 0= IF exit THEN
2dup last -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' )
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-03-13 14:06 -0700 |
| Message-ID | <1f40ded5-3783-42de-970a-b951cc2495b5@googlegroups.com> |
| In reply to | #46035 |
On Sunday, March 13, 2016 at 8:25:28 AM UTC-7, humptydumpty wrote:
> 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='.
I wondered about that 0 <= but it didn't do any harm so I didn't comment on it --- I assumed that you were checking for the user giving a negative length.
> Yes, 'darken' is stacks hungry :) Somehow could be cured using a buffer
> of fixed convenient size .
The problem of course is that you don't know what a convenient size would be. A person could have a string thousands of chars long. Most strings are going to be no more than 100 chars long though, so your fixed buffer would just be sitting there wasting memory.
Using the return-stack should work pretty well. The return-stack is usually provided with a lot of memory because it is sometimes used to call C functions internally.
> But what I think is cool - that 'darken' could be a prototype
> for general unix-like filters for arrays of pointers to data.
In string-stack.4th I have some code that does something like this. Note that FIRST$ ITEM@ provides the adr and cnt for the string. Also, an item has two fields which are .ADR$ and .CNT$ --- here is the code:
: forward$ { xt -- index | -1 } \ returns the index where it stopped, or -1 if it went all the way
\ xt function stack-picture: i*x char-adr -- j*x done?
first$ item@
bounds ?do
I xt execute if
I first$ .adr$ @ -
unloop exit then
loop
-1 ;
: backward$ { xt -- index | -1 } \ returns the index where it stopped, or -1 if it went all the way
\ xt function stack-picture: i*x char-adr -- j*x done?
first$ item@
over + 1- \ -- first-adr last-adr
2dup u< if
do
I xt execute if
I first$ .adr$ @ -
unloop exit then
-1 +loop
else
2drop then
-1 ;
\ If FORWARD$ or BACKWARD$ are used to modify a string, be sure to use PREP-MUTATION first.
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-03-07 16:28 -0800 |
| Message-ID | <-7mdncbmo6MjgUPLnZ2dnUU7-e3NnZ2d@supernews.com> |
| In reply to | #45860 |
On 3/5/16 10:59 AM, rickman wrote: > 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. I agree with Rick, but if students are assigned a series of problems, with varying degrees of challenge and differing topics, they will make their own broken problems and work out how to debug them. Having a coach looking over their shoulders helps, if the coaching is done right: don't tell them what they're doing wrong, but ask questions, like, "what's on the stack at this point?" >>> 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... Requires a lot of preparation from the course designer. This valuable lesson can, as above, been achieved using the students' own code by assigning a simple version of the problem, and then adding complexity. >>> 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. Yes, but IMO the lesson sinks in better when it's the student's own code. 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 | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-03-07 19:39 -0500 |
| Message-ID | <nbl6q0$ee6$1@dont-email.me> |
| In reply to | #45929 |
On 3/7/2016 7:28 PM, Elizabeth D. Rather wrote: > On 3/5/16 10:59 AM, rickman wrote: >> On 3/5/2016 11:54 AM, Ron Aaron wrote: >>> On 04/03/2016 21:11, Julian Fondren wrote: >>> > >>>> 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. > > Yes, but IMO the lesson sinks in better when it's the student's own code. I have a number of friends who are teachers and one of the things I have learned about their methods is to teach things in multiple ways. I think that could apply here too. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | Bernd Paysan <bernd.paysan@gmx.de> |
|---|---|
| Date | 2016-03-08 22:13 +0000 |
| Message-ID | <nbniq2$cs0$2@dont-email.me> |
| In reply to | #45930 |
Am Mon, 07 Mar 2016 19:39:20 -0500 schrieb rickman: > On 3/7/2016 7:28 PM, Elizabeth D. Rather wrote: >> On 3/5/16 10:59 AM, rickman wrote: >>> On 3/5/2016 11:54 AM, Ron Aaron wrote: >>>> On 04/03/2016 21:11, Julian Fondren wrote: >>>> >>>> >>>>> 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. >> >> Yes, but IMO the lesson sinks in better when it's the student's own >> code. > > I have a number of friends who are teachers and one of the things I have > learned about their methods is to teach things in multiple ways. I > think that could apply here too. Of course, that always applies. Another point is that "own code" is code where the student remembers things he has not written down. It is his own code, written an hour ago, and he still remembers the stack juggling. Maybe half a year later he would have forgotten that, but now it is fresh, so it's still in memory. People tend to write code they can't understand half a year later. Now you don't have half a year for that lesson, so by using code written by someone else you can mimic that effect: The code is as undocumented and as long-winding as the student's own code, but there is no memory annotation to understand it. It is code that sucks, and it has to be rewritten (programmers like to do that); but since there is no spec and it's only crashing sometimes, you can't do that from scratch. You could use the students to produce the buggy code for review, just take some not-quite-working homework and let the other students figure out what went wrong. Saves some time for the professor: Instead of correcting the homework himself, he can let the students do that. -- 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 | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-03-09 01:18 +0000 |
| Message-ID | <56df79ee$0$24106$e4fe514c@news.xs4all.nl> |
| In reply to | #45942 |
Bernd Paysan <bernd.paysan@gmx.de> writes: >Am Mon, 07 Mar 2016 19:39:20 -0500 schrieb rickman: >> On 3/7/2016 7:28 PM, Elizabeth D. Rather wrote: >>> On 3/5/16 10:59 AM, rickman wrote: >>>> On 3/5/2016 11:54 AM, Ron Aaron wrote: >>>>> On 04/03/2016 21:11, Julian Fondren wrote: >>>>> >>>>> >>>>>> 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. >>> >>> Yes, but IMO the lesson sinks in better when it's the student's own >>> code. >> >> I have a number of friends who are teachers and one of the things I have >> learned about their methods is to teach things in multiple ways. I >> think that could apply here too. >Of course, that always applies. >Another point is that "own code" is code where the student remembers >things he has not written down. It is his own code, written an hour ago, >and he still remembers the stack juggling. Maybe half a year later he >would have forgotten that, but now it is fresh, so it's still in memory. >People tend to write code they can't understand half a year later. >Now you don't have half a year for that lesson, so by using code written >by someone else you can mimic that effect: The code is as undocumented >and as long-winding as the student's own code, but there is no memory >annotation to understand it. It is code that sucks, and it has to be >rewritten (programmers like to do that); but since there is no spec and >it's only crashing sometimes, you can't do that from scratch. >You could use the students to produce the buggy code for review, just >take some not-quite-working homework and let the other students figure >out what went wrong. Saves some time for the professor: Instead of >correcting the homework himself, he can let the students do that. Or you can have a first assigment. The programs that pass, are randomly redistributed amongst the students and they are asked to add a feature. They must report, and their grade depends on the report, and quality added to the program, not on whether they succeeded in adding the feature to what may be a disastrous (but working) program. >-- >Bernd Paysan Groetjes Albert -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2016-03-08 20:41 -0500 |
| Message-ID | <nbnupr$v6v$1@dont-email.me> |
| In reply to | #45944 |
On 3/8/2016 8:18 PM, Albert van der Horst wrote: > > Or you can have a first assigment. The programs that pass, are randomly > redistributed amongst the students and they are asked to add a feature. > They must report, and their grade depends on the report, and quality > added to the program, not on whether they succeeded in adding the > feature to what may be a disastrous (but working) program. Just giving out assignments and grading the results isn't teaching. Teaching is getting the lightbulb to come on. You have to interact with them in ways that shows them something they would not have figured out easily on their own. -- Rick
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-03-10 22:33 -0800 |
| Message-ID | <d8ednUCt07Qs-3_LnZ2dnUU7-SGdnZ2d@supernews.com> |
| In reply to | #45945 |
On 3/8/16 5:41 PM, rickman wrote:
> On 3/8/2016 8:18 PM, Albert van der Horst wrote:
>>
>> Or you can have a first assigment. The programs that pass, are randomly
>> redistributed amongst the students and they are asked to add a feature.
>> They must report, and their grade depends on the report, and quality
>> added to the program, not on whether they succeeded in adding the
>> feature to what may be a disastrous (but working) program.
>
> Just giving out assignments and grading the results isn't teaching.
> Teaching is getting the lightbulb to come on. You have to interact with
> them in ways that shows them something they would not have figured out
> easily on their own.
^ ^ ^ ^ ^ ^
What he said! Very important!
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-10 23:17 -0800 |
| Message-ID | <d7c9407f-06f6-41c7-b37a-8cf183352e29@googlegroups.com> |
| In reply to | #45969 |
On Thursday, March 10, 2016 at 11:33:23 PM UTC-7, Elizabeth D. Rather wrote: > On 3/8/16 5:41 PM, rickman wrote: > > On 3/8/2016 8:18 PM, Albert van der Horst wrote: > >> > >> Or you can have a first assigment. The programs that pass, are randomly > >> redistributed amongst the students and they are asked to add a feature. > >> They must report, and their grade depends on the report, and quality > >> added to the program, not on whether they succeeded in adding the > >> feature to what may be a disastrous (but working) program. > > > > Just giving out assignments and grading the results isn't teaching. > > Teaching is getting the lightbulb to come on. You have to interact with > > them in ways that shows them something they would not have figured out > > easily on their own. > > ^ ^ ^ ^ ^ ^ > What he said! Very important! Writing code that works is important --- "getting the light-bulb to come on" is feel-good horse-shit --- you have never programmed, but all you do is teach, and you know nothing about programming. > Cheers, > Elizabeth Shut up, stupid! First John Passaniti, then Alex McDonald, now Rickman --- a parade of non-programming internet-experts --- I'm happy to see that you have chosen Rickman however, because John Passaniti and Alex McDonald have both gotten tired of you patting them on the head and have left, so if this pattern holds, Rickman will leave pretty soon too...
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-03-13 14:41 -0700 |
| Message-ID | <694787d1-860d-4bed-8bf9-722bfba32c7e@googlegroups.com> |
| In reply to | #45969 |
On Thursday, March 10, 2016 at 11:33:23 PM UTC-7, Elizabeth D. Rather wrote:
> On 3/8/16 5:41 PM, rickman wrote:
> > Just giving out assignments and grading the results isn't teaching.
> > Teaching is getting the lightbulb to come on. You have to interact with
> > them in ways that shows them something they would not have figured out
> > easily on their own.
>
> ^ ^ ^ ^ ^ ^
> What he said! Very important!
>
> Cheers,
> Elizabeth
Getting back to the subject of teaching, which everybody on comp.lang.forth seems to be an expert on, lets consider what happens when we teach the student how DO loops work. Our first assignment is to write a word that does what TYPE does. The student writes this:
: my-type ( adr cnt -- )
over + swap do
I c@ emit loop ;
This is a pretty good try, except that it doesn't work given an empty string. The correct answer is this:
: my-type ( adr cnt -- )
over + swap ?do
I c@ emit loop ;
The student wonders why ANS-Forth provides DO when ?DO is what programmers need every time. There is no example of when DO would be preferred to ?DO so DO should have been made obsolete and only ?DO provided. The answer is that Charles Moore originally thought up DO and only later realized that ?DO was needed. ANS-Forth contains a lot of cruft from the 1970s. ANS-Forth represents the state-of-the-art in Forth circa about 1978.
The student feels confident and he says: "I understand how ?DO works!" Hooray! "Teaching is getting the light-bulb to come on."
The student feels so confident that he says: "Now I will write a version of TYPE that goes backwards!" The student writes this:
: my-backward-type ( adr cnt -- )
over + swap
2dup ?do I c@ >r loop
?do r> emit loop ;
The student says: "This Forth stuff is easy!" When he runs his function however it crashes the Forth system. The student says: "WTF??? Was there a bug in my code?"
The answer is that there is a bug in the ANS-Forth Standard. In the 1970s the most common processor was the PDP-11 which had only 8 registers (including the program-counter). Because of this register shortage, some registers had to be used for multiple unrelated purposes, and the programmer just had to be careful that the different uses of the same register didn't clash with each other. In Forth, the return-stack (register R6) was used for return-addresses, >R data and DO loop data. So, >R and DO clash with each other and can't be used together. The obvious solution in 1994 is to use different registers for >R data and DO loop data so they can be used together. As I said before though: ANS-Forth contains a lot of cruft from the 1970s. ANS-Forth represents the state-of-the-art in Forth circa about 1978.
The correct answer is this:
: my-backward-type ( adr cnt -- )
over + 1-
2dup u< if
do I c@ emit -1 +loop
else
2drop then ;
When the student sees this he runs away screaming. Effectively the ANS-Forth committee have emptied their bowels on top of the light-bulb. The light-bulb has been crushed underneath a great steaming pile of Standard (or some other word that starts with an 'S').
In summary: the reason why people fail to learn Forth is because the ANS-Forth Standard is stupid and the students just leave.
BTW: It took me three tries before I finally got BACKWARD$ shown above to work correctly. FORWARD$ was trivial, but BACKWARD$ was pretty puzzling. I've been programming in Forth for 30 years, and DO loops still trip me up --- I can only imagine how puzzled the novice Forth programmer must be --- I don't blame the novice for abandoning ANS-Forth (I would too if I were 18 again, but it is too late for me now).
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <julian.fondren@gmail.com> |
|---|---|
| Date | 2016-03-13 17:26 -0700 |
| Message-ID | <f50819c8-11fd-48e6-a1d2-8870c29b313a@googlegroups.com> |
| In reply to | #46043 |
On Sunday, March 13, 2016 at 4:41:34 PM UTC-5, hughag...@gmail.com wrote:
>
> Getting back to the subject of teaching, which everybody on comp.lang.forth seems to be an expert on, lets consider what happens when we teach the student how DO loops work. Our first assignment is to write a word that does what TYPE does. The student writes this:
>
> : my-type ( adr cnt -- )
> over + swap do
> I c@ emit loop ;
>
> This is a pretty good try, except that it doesn't work given an empty string. The correct answer is this:
>
> : my-type ( adr cnt -- )
> over + swap ?do
> I c@ emit loop ;
>
> The student wonders why ANS-Forth provides DO when ?DO is what programmers need every time.
When DO ... LOOP is used in the sense of "do something X times",
and when the appropriate response to "do something 0 times" is
to skip the body of the loop, then you usually want ?DO
And you usually do want ?DO because those are usually the
circumstances of a counted loop.
But there are also cases where "doing something 0 times" is an
error. And there are other potentially erroneous inputs like
( -1 5 ) or ( 234349 -5 ). And the error-checking that would
prevent these inputs doesn't necessarily belong near the loop
itself -- actually if you get ( -1 0 ) you might find that ?DO
would only serve to hide error by doing nothing.
Forth is not a language that requires you to riddle your code
with redundant checks.
> The student feels so confident that he says: "Now I will write a version of TYPE that goes backwards!" The student writes this:
>
> : my-backward-type ( adr cnt -- )
> over + swap
> 2dup ?do I c@ >r loop
> ?do r> emit loop ;
>
> The student says: "This Forth stuff is easy!" When he runs his function however it crashes the Forth system. The student says: "WTF??? Was there a bug in my code?"
>
> [summary of ommitted text: DO shouldn't use the return stack]
Other constructs can use the return stack. Someone learning
Forth may as well get used to keeping that in mind and paying
attention to these constructs. For example I have
emails[ .... ]emails
files[ ... ]files
which modify the return stack when they set the current object to
each email or file in turn.
>
> The correct answer is this:
>
> : my-backward-type ( adr cnt -- )
> over + 1-
> 2dup u< if
> do I c@ emit -1 +loop
> else
> 2drop then ;
>
> When the student sees this he runs away screaming.
*shrug* BOUNDS SWAP 1- DO ... -1 +LOOP handles everything
except the empty string. If it's a little bit awkward to set
things up for DO you can always fall back on more straightforward
code. Which is the kind of code you might write anyway for a
more interesting data structure.
: type-backwards ( 'string' -- f )
begin dup while
2dup last-c@ emit
1- repeat 2drop ;
: do-backwards {: xt -- :} \ o: array subclass
last-index begin this-index? while
xt execute
prev-index repeat ;
-- Julian
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-03-13 21:46 -1000 |
| Message-ID | <wc-dnfibrsby8XvLnZ2dnUU7-fvNnZ2d@supernews.com> |
| In reply to | #46046 |
On 3/13/16 2:26 PM, Julian Fondren wrote:
> On Sunday, March 13, 2016 at 4:41:34 PM UTC-5, hughag...@gmail.com wrote:
>>
>> Getting back to the subject of teaching, which everybody on comp.lang.forth seems to be an expert on, lets consider what happens when we teach the student how DO loops work. Our first assignment is to write a word that does what TYPE does. The student writes this:
>>
>> : my-type ( adr cnt -- )
>> over + swap do
>> I c@ emit loop ;
>>
>> This is a pretty good try, except that it doesn't work given an empty string. The correct answer is this:
>>
>> : my-type ( adr cnt -- )
>> over + swap ?do
>> I c@ emit loop ;
>>
>> The student wonders why ANS-Forth provides DO when ?DO is what programmers need every time.
>
> When DO ... LOOP is used in the sense of "do something X times",
> and when the appropriate response to "do something 0 times" is
> to skip the body of the loop, then you usually want ?DO
>
> And you usually do want ?DO because those are usually the
> circumstances of a counted loop.
>
> But there are also cases where "doing something 0 times" is an
> error. And there are other potentially erroneous inputs like
> ( -1 5 ) or ( 234349 -5 ). And the error-checking that would
> prevent these inputs doesn't necessarily belong near the loop
> itself -- actually if you get ( -1 0 ) you might find that ?DO
> would only serve to hide error by doing nothing.
>
> Forth is not a language that requires you to riddle your code
> with redundant checks.
In a great many cases the programmer knows, because of environmental
issues or other checks elsewhere, that the DO arguments are going to be
legal (i.e., ?DO not relevant). In those cases, the redundant check is a
waste of cycles.
As a matter of program design, arguments should be checked as soon as
they enter the system: at the user interface, read from a device, or
whatever. If this is done rigorously, a great many internal checks can
be safely omitted, leaving the program smaller, faster, and cleaner.
>> The student feels so confident that he says: "Now I will write a
>> version of TYPE that goes backwards!" The student writes this:
>>
>> : my-backward-type ( adr cnt -- )
>> over + swap
>> 2dup ?do I c@ >r loop
>> ?do r> emit loop ;
>>
>> The student says: "This Forth stuff is easy!" When he runs his
>> function however it crashes the Forth system. The student says:
>> "WTF??? Was there a bug in my code?"
>>
>> [summary of ommitted text: DO shouldn't use the return stack]
Um, yeah, every introduction of DO ... LOOP & friends needs to stress this.
> Other constructs can use the return stack. Someone learning
> Forth may as well get used to keeping that in mind and paying
> attention to these constructs. For example I have
>
> emails[ .... ]emails
> files[ ... ]files
>
> which modify the return stack when they set the current object to
> each email or file in turn.
Sounds like a risky and potentially non-portable design, to me.
>>
>> The correct answer is this:
>>
>> : my-backward-type ( adr cnt -- )
>> over + 1-
>> 2dup u< if
>> do I c@ emit -1 +loop
>> else
>> 2drop then ;
>>
>> When the student sees this he runs away screaming.
>
> *shrug* BOUNDS SWAP 1- DO ... -1 +LOOP handles everything
> except the empty string. If it's a little bit awkward to set
> things up for DO you can always fall back on more straightforward
> code. Which is the kind of code you might write anyway for a
> more interesting data structure.
>
> : type-backwards ( 'string' -- f )
> begin dup while
> 2dup last-c@ emit
> 1- repeat 2drop ;
>
> : do-backwards {: xt -- :} \ o: array subclass
> last-index begin this-index? while
> xt execute
> prev-index repeat ;
>
> -- Julian
>
--
==================================================
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-14 08:12 -0700 |
| Message-ID | <dd125f82-25db-482a-99bd-5f552e425b1a@googlegroups.com> |
| In reply to | #46052 |
On Monday, March 14, 2016 at 12:46:57 AM UTC-7, Elizabeth D. Rather wrote: > On 3/13/16 2:26 PM, Julian Fondren wrote: > >> The student feels so confident that he says: "Now I will write a > >> version of TYPE that goes backwards!" The student writes this: > >> > >> : my-backward-type ( adr cnt -- ) > >> over + swap > >> 2dup ?do I c@ >r loop > >> ?do r> emit loop ; > >> > >> The student says: "This Forth stuff is easy!" When he runs his > >> function however it crashes the Forth system. The student says: > >> "WTF??? Was there a bug in my code?" > >> > >> [summary of ommitted text: DO shouldn't use the return stack] > > Um, yeah, every introduction of DO ... LOOP & friends needs to stress this. You're imposing your own incompetence on Forth. We are not using the PDP-11 with its extreme register shortage anymore --- even small micro-controllers such as the MSP-430 have 16 registers --- we don't need to dedicate a register to multiple unrelated purposes and then require the user to avoid clashes. BTW: Nobody over the age of 12 thinks that it is cute to say: "Um, yeah..." In summary: Shut up, stupid!
[toc] | [prev] | [next] | [standalone]
| From | Albert van der Horst <albert@spenarnc.xs4all.nl> |
|---|---|
| Date | 2016-03-14 17:45 +0000 |
| Message-ID | <56e6f8d6$0$24112$e4fe514c@news.xs4all.nl> |
| In reply to | #46052 |
"Elizabeth D. Rather" <erather@forth.com> writes: <SNIP> >In a great many cases the programmer knows, because of environmental >issues or other checks elsewhere, that the DO arguments are going to be >legal (i.e., ?DO not relevant). In those cases, the redundant check is a >waste of cycles. I've to side with Hugh here. Forth is sufficiently slow that the extra cycles don't matter. Then there are implementations like iforth that optimize (= speed up) the behezus of everything, and can make sure that the zero case doesn't waste cycles anyway. So we don't need DO. I only use it because ?DO looks puzzling, showing that what it is, an afterthought. <SNIP> >Elizabeth D. Rather (US & Canada) 800-55-FORTH P.S. [ I just side with Hugh on this particular technical point. I find the repeated insults towards you despicable.] -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst
[toc] | [prev] | [next] | [standalone]
| From | "Elizabeth D. Rather" <erather@forth.com> |
|---|---|
| Date | 2016-03-14 14:11 -1000 |
| Message-ID | <YuqdnaXt0f2LznrLnZ2dnUU7-fvNnZ2d@supernews.com> |
| In reply to | #46060 |
On 3/14/16 7:45 AM, Albert van der Horst wrote: > "Elizabeth D. Rather" <erather@forth.com> writes: > <SNIP> >> In a great many cases the programmer knows, because of environmental >> issues or other checks elsewhere, that the DO arguments are going to be >> legal (i.e., ?DO not relevant). In those cases, the redundant check is a >> waste of cycles. > > I've to side with Hugh here. Forth is sufficiently slow that the extra > cycles don't matter. Then there are implementations like iforth > that optimize (= speed up) the behezus of everything, and can make sure > that the zero case doesn't waste cycles anyway. > So we don't need DO. I only use it because ?DO looks puzzling, showing > that what it is, an afterthought. In another thread, some timings were posted recently that showed the better Forth implementations performing quite well in comparison with other languages. I never like to see cycles, bytes, or anything else wasted. > <SNIP> >> Elizabeth D. Rather (US & Canada) 800-55-FORTH > > P.S. > [ I just side with Hugh on this particular technical point. > I find the repeated insults towards you despicable.] Thank you. I have blocked his posts, so I never see them. 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-15 01:13 -0700 |
| Message-ID | <5390e24a-bda1-43bb-beea-ae76c2b241dd@googlegroups.com> |
| In reply to | #46070 |
On Monday, March 14, 2016 at 5:11:04 PM UTC-7, Elizabeth D. Rather wrote:
> On 3/14/16 7:45 AM, Albert van der Horst wrote:
> > "Elizabeth D. Rather" <erather@forth.com> writes:
> > <SNIP>
> >> In a great many cases the programmer knows, because of environmental
> >> issues or other checks elsewhere, that the DO arguments are going to be
> >> legal (i.e., ?DO not relevant). In those cases, the redundant check is a
> >> waste of cycles.
> >
> > I've to side with Hugh here. Forth is sufficiently slow that the extra
> > cycles don't matter. Then there are implementations like iforth
> > that optimize (= speed up) the behezus of everything, and can make sure
> > that the zero case doesn't waste cycles anyway.
> > So we don't need DO. I only use it because ?DO looks puzzling, showing
> > that what it is, an afterthought.
>
> In another thread, some timings were posted recently that showed the
> better Forth implementations performing quite well in comparison with
> other languages. I never like to see cycles, bytes, or anything else
> wasted.
Well, since you "never like to see cycles, bytes, or anything else wasted" lets look at how well SwiftForth compiles code.
Here is a simple function:
: reverse ( adr len -- ) \ reverse the chars in the string
2dup + -rot \ -- limit-adr adr cnt
2/ bounds ?do 1- \ -- last-adr
dup c@ I c@ \ -- last-adr last-char char
rover c! I c! loop
drop ;
This is the generated code in SwiftForth:
see reverse
48E74F 4 # EBP SUB 83ED04
48E752 EBX 0 [EBP] MOV 895D00
48E755 4 [EBP] EAX MOV 8B4504
48E758 EBX EAX ADD 01D8
48E75A EAX EBX MOV 8BD8
48E75C EBX ECX MOV 8BCB
48E75E 4 [EBP] EAX MOV 8B4504
48E761 0 [EBP] EBX MOV 8B5D00
48E764 EAX 0 [EBP] MOV 894500
48E767 ECX 4 [EBP] MOV 894D04
48E76A EBX SAR D1FB
48E76C 0 [EBP] EBX ADD 035D00
48E76F 0 [EBP] EAX MOV 8B4500
48E772 EBX 0 [EBP] MOV 895D00
48E775 EAX EBX MOV 8BD8
48E777 0 [EBP] EBX CMP 3B5D00
48E77A 48E787 JNZ 750B
48E77C 4 [EBP] EBX MOV 8B5D04
48E77F 8 # EBP ADD 83C508
48E782 48E7E2 JMP E95B000000
48E787 40421F ( (DO) ) CALL E8935AF7FF
48E78C EBX DEC 4B
48E78D 4 # EBP SUB 83ED04
48E790 EBX 0 [EBP] MOV 895D00
48E793 EAX EAX XOR 31C0
48E795 0 [EBX] AL MOV 8A03
48E797 EAX EBX MOV 8BD8
48E799 4 # EBP SUB 83ED04
48E79C EBX 0 [EBP] MOV 895D00
48E79F EBX EBX XOR 31DB
48E7A1 0 [ESP] EAX MOV 8B0424
48E7A4 4 [ESP] EAX ADD 03442404
48E7A8 0 [EAX] BL MOV 8A18
48E7AA 4 # EBP SUB 83ED04
48E7AD EBX 0 [EBP] MOV 895D00
48E7B0 8 [EBP] EBX MOV 8B5D08
48E7B3 0 [EBP] EAX MOV 8B4500
48E7B6 AL 0 [EBX] MOV 8803
48E7B8 4 [EBP] EBX MOV 8B5D04
48E7BB 8 # EBP ADD 83C508
48E7BE 4 # EBP SUB 83ED04
48E7C1 EBX 0 [EBP] MOV 895D00
48E7C4 0 [ESP] EBX MOV 8B1C24
48E7C7 4 [ESP] EBX ADD 035C2404
48E7CB 0 [EBP] EAX MOV 8B4500
48E7CE AL 0 [EBX] MOV 8803
48E7D0 4 [EBP] EBX MOV 8B5D04
48E7D3 8 # EBP ADD 83C508
48E7D6 0 [ESP] INC FF0424
48E7D9 48E78C JNO 0F81ADFFFFFF
48E7DF 8 # ESP ADD 83C408
48E7E2 0 [EBP] EBX MOV 8B5D00
48E7E5 4 # EBP ADD 83C504
48E7E8 RET C3 ok
see (do)
40421F EDX POP 5A
404220 0 [EBP] EAX MOV 8B4500
404223 -80000000 # EAX ADD 0500000080
404228 EAX PUSH 50
404229 EAX EBX SUB 29C3
40422B EBX PUSH 53
40422C 4 [EBP] EBX MOV 8B5D04
40422F 8 # EBP ADD 83C508
404232 EDX JMP FFE2 ok
This is the generated code in VFX:
see reverse
REVERSE
( 004DF330 8BD3 ) MOV EDX, EBX
( 004DF332 035D00 ) ADD EBX, [EBP]
( 004DF335 D1FA ) SAR EDX, 1
( 004DF337 035500 ) ADD EDX, [EBP]
( 004DF33A 6888F34D00 ) PUSH 004DF388
( 004DF33F 8BCA ) MOV ECX, EDX
( 004DF341 81F100000080 ) XOR ECX, 80000000
( 004DF347 2B4D00 ) SUB ECX, [EBP]
( 004DF34A F7D9 ) NEG ECX
( 004DF34C 51 ) PUSH ECX
( 004DF34D FF7500 ) PUSH [EBP]
( 004DF350 8D6D04 ) LEA EBP, [EBP+04]
( 004DF353 817C240400000080 ) CMP [ESP+04], 80000000
( 004DF35B 7505 ) JNZ/NE 004DF362
( 004DF35D 8D642408 ) LEA ESP, [ESP+08]
( 004DF361 C3 ) NEXT,
( 004DF362 90 ) NOP
( 004DF363 90 ) NOP
( 004DF364 90 ) NOP
( 004DF365 90 ) NOP
( 004DF366 90 ) NOP
( 004DF367 90 ) NOP
( 004DF368 4B ) DEC EBX
( 004DF369 0FB613 ) MOVZX EDX, Byte Ptr 0 [EBX]
( 004DF36C 8B0C24 ) MOV ECX, [ESP]
( 004DF36F 0FB609 ) MOVZX ECX, Byte Ptr 0 [ECX]
( 004DF372 880B ) MOV 0 [EBX], CL
( 004DF374 8B0C24 ) MOV ECX, [ESP]
( 004DF377 8811 ) MOV 0 [ECX], DL
( 004DF379 83042401 ) ADD [ESP], 01
( 004DF37D 8344240401 ) ADD [ESP+04], 01
( 004DF382 71E4 ) JNO 004DF368
( 004DF384 8D64240C ) LEA ESP, [ESP+0C]
( 004DF388 8B5D00 ) MOV EBX, [EBP]
( 004DF38B 8D6D04 ) LEA EBP, [EBP+04]
( 004DF38E C3 ) NEXT,
( 95 bytes, 36 instructions )
ok
> > P.S.
> > [ I just side with Hugh on this particular technical point.
> > I find the repeated insults towards you despicable.]
>
> Thank you. I have blocked his posts, so I never see them.
Albert is delusional if he believes that there is a middle-ground. Either a person brown-noses Elizabeth Rather or the person concerns himself with technical points, but it is impossible to do both --- there is no middle ground.
The {: issue is a good example. If a programmer hasn't already written { and the Forth-200x committee says that {: is the standard, the programmer is not realistically going to write { and go against the Forth-200x committee but he is just going to use the {: that is standard. When the bugs in {: that I described earlier become obvious, the programmer will just shrug and say: "The bugs aren't my fault --- this is just how Forth is --- being a Forth programmer means living with bugs."
If the programmer already has 25 years worth of legacy code using { then changing all of that to use {: is going to be painful. If the programmer has written { himself (as I did in the novice package), then the situation is going to be even more painful --- the programmer is in the awkward position of having to apologize to Elizabeth Rather for writing bug-free code and accept the standard {: with its bugs.
Similarly, Elizabeth Rather said this about my novice-package:
"Does '*every* application' you write use exactly the same kind of data arranged in the same way? If so, having written it once you can reuse it often. If not, you either have to rearrange your data to make it work or modify your 'general-purpose' structure."
She is never going to back down from this statement. This puts me in the awkward position of having to apologize for writing general-purpose data-structures in the novice-package and agree with her that general-purpose data-structures are impossible.
Really, every line of code in the novice-package contradicts Elizabeth Rather's concept of what Forth programming is. The only way that I could appease Elizabeth Rather would be to completely abandon all of that code and agree with her that it is impossible. I would have to go back to using PAD again, like I did when I was 18 years old and just barely learning Forth. Even when I was 18 however, I knew that PAD was a bad idea because it is not reentrant. So now I not only have to go back to using PAD but I also have to revert my thinking to a time when I didn't know what reentrancy was (about the age of 15 when I was programming in line-number BASIC.
This is like in the book 1984 in which Winston Smith was required to believe things which he knew to be untrue. At the end of the book, Winston Smith really believes in the war that the television tells him to believe in, and he says so. Similarly, I would have to say this:
"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."
Not only would I have to say this, but I would like Winston Smith have to truly believe it in my heart. This is what it means to be an ANS-Forth programmer --- to truly believe everything that Elizabeth Rather says, despite it being obviously untrue.
Until I can achieve this astounding level of double-think, I will have to put up with Albert van der Horst telling me that I'm "despicable." This is another example:
https://groups.google.com/forum/#!searchin/comp.lang.forth/lc53/comp.lang.forth/qqlp1gZnVic/kjeAwWCaR1MJ
I continue to write Forth code --- none of this has stopped me yet.
> Cheers,
> Elizabeth
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-03-14 08:55 -0700 |
| Message-ID | <2226c6cf-bca6-4031-ba45-af3e15b42b95@googlegroups.com> |
| In reply to | #46046 |
On Sunday, March 13, 2016 at 5:26:12 PM UTC-7, Julian Fondren wrote:
> : do-backwards {: xt -- :} \ o: array subclass
> last-index begin this-index? while
> xt execute
> prev-index repeat ;
>
> -- Julian
The use of {: is grotesque brown-nosing of Elizabeth Rather.
The Forth community has used { for about 25 years. The reason why Anton Ertl changed the name to {: was because SwiftForth uses { for multi-line comments. When Anton Ertl changed the name to {: and pulled the rug out from under a quarter-century of legacy code, he was totally snubbing the entire Forth community --- this really shows that the boss of Forth-200x is Leon Wagner and that Anton Ertl the supposed chair-person is just a puppet of Forth Inc..
Anton Ertl also has two major bugs in is {: implementation:
1.) The locals to the right of the | are not initialized to zero (the correct implementation) but are instead initialized to whatever happened to be in memory previously. This means that the behavior of the program will differ from one compilation to the next --- a program that does what is expected given one compilation may fail given another compilation (for example, the production compile that the customer will see). This is actually the kind of bug that a first-year programmer might make. Anton Ertl refuses to fix the bug because he says that his code was written according to spec and hence is correct, but the problem is in the spec which he doesn't have the authority to change (the spec was provided by Leon Wagner of Forth Inc.).
2.) In SwiftForth-v2 the use of (LOCAL) will crash they system. The use of LOCALS| works however. Because of this, when I wrote { in the novice-package I used LOCALS| so my code will work under SwiftForth-v2. Anton Ertl used (LOCAL) in his implementation of {: --- I think he did this purposely so that {: would fail under SwiftForth-v2 and the people who paid over $400 for SwiftForth-v2 (including myself) would be forced to pay Forth Inc. a $300 upgrade fee to obtain SwiftForth-v3 in which the (LOCAL) bug has been fixed. Anton Ertl is effectively working as a salesman for Forth Inc. by forcing the SwiftForth-v2 owners into a situation where they have to pay Forth Inc. $300 in order for their code to work.
So, why did you use {: instead of { in your code? The choice of {: over { is obviously a political statement. I think that you were brown-nosing Elizabeth Rather in the expectation that she would give you some praise in return --- she always responds with praise for blind obedience and non-thinking acquiescence --- maybe she will hire you to be a salesman for Forth Inc..
Aloha!
Hugh
[toc] | [prev] | [next] | [standalone]
| From | Julian Fondren <ayrnieu@gmail.com> |
|---|---|
| Date | 2016-03-15 03:16 -0700 |
| Message-ID | <4d59e6f8-0583-4746-971b-8545d9c603ba@googlegroups.com> |
| In reply to | #46059 |
On Monday, March 14, 2016 at 10:55:32 AM UTC-5, hughag...@gmail.com wrote:
> On Sunday, March 13, 2016 at 5:26:12 PM UTC-7, Julian Fondren wrote:
> > : do-backwards {: xt -- :} \ o: array subclass
> > last-index begin this-index? while
> > xt execute
> > prev-index repeat ;
> >
> > -- Julian
>
> The use of {: is grotesque brown-nosing [...]
> [...]
> The choice of {: over { is obviously a political statement.
Thank you for your report. That code was NOT written by me. It
was written by a member of my staff -- a former member, as I've
let him go with prejudice in direct response to your report.
The corrected code follows:
\ Written in the current year.
\ This code is released under a modified 2-clause BSD.
\ The modification is this additional clause: It is FORBIDDEN
\ to load this code into any Forth system which can be used to
\ write a CROSS COMPILER.
require objects.fs
require PortableSwoop.f
require FMS-SI.f
\ OBJ is passed to XT with indexes starting from end, to beginning
\ xt: should receive OBJ ; and then return OBJ back to caller
: Iterate-Chars-Backwards ( obj xt )
\G * higher-order string reverse-iterator
[OBJECTS function NAMES xt OBJECTS] ( obj )
DEBUG: <timer ['] exttime. [IS] time. ( obj )
DUP string.last-index ( obj )
BEGIN ( obj )
DUP string.this-index? ( obj u )
WHILE ( obj )
xt INVOKE ( obj )
string.prev-index ( obj )
REPEAT ( obj )
( obj )
DUP <allocation> 0> IF ( obj )
free ABORT" *** failure to free memory ***" ( )
ELSE ( obj )
DROP ( MAKE AMERICA GREAT AGAIN ) ( )
THEN ( )
DEBUG: timer> cr ." out iter took: " time. ( )
; ( )
\ XXX: remove stack comments before publishing!
-- Julian
[toc] | [prev] | [next] | [standalone]
| From | hughaguilar96@gmail.com |
|---|---|
| Date | 2016-03-16 16:13 -0700 |
| Message-ID | <c1770cc4-02e5-41eb-854a-1e188d30b531@googlegroups.com> |
| In reply to | #46046 |
On Sunday, March 13, 2016 at 5:26:12 PM UTC-7, Julian Fondren wrote:
> On Sunday, March 13, 2016 at 4:41:34 PM UTC-5, hughag...@gmail.com wrote:
> > The student feels so confident that he says: "Now I will write a version of TYPE that goes backwards!" The student writes this:
> >
> > : my-backward-type ( adr cnt -- )
> > over + swap
> > 2dup ?do I c@ >r loop
> > ?do r> emit loop ;
> >
> > The student says: "This Forth stuff is easy!" When he runs his function however it crashes the Forth system. The student says: "WTF??? Was there a bug in my code?"
> >
> > [summary of ommitted text: DO shouldn't use the return stack]
One of the stated goals of ANS-Forth was to standardize behavior rather than standardize implementation. This is a noble goal! Unfortunately, ANS-Forth failed at this repeatedly. DO loops and >R both use the same stack --- this was done in the 1970s because the PDP-11 had a shortage of registers, so R6 was used for both --- this didn't belong in ANS-Forth, not just because the PDP-11 implementation was obsolete, but because the goal was to not standardize implementation at all.
> > The correct answer is this:
> >
> > : my-backward-type ( adr cnt -- )
> > over + 1-
> > 2dup u< if
> > do I c@ emit -1 +loop
> > else
> > 2drop then ;
> >
> > When the student sees this he runs away screaming.
>
> *shrug* BOUNDS SWAP 1- DO ... -1 +LOOP handles everything
> except the empty string. If it's a little bit awkward to set
> things up for DO you can always fall back on more straightforward
> code.
BOUNDS is defined in the novice package as:
macro: bounds ( adr cnt -- past-adr adr )
over + swap ;
Your BOUNDS SWAP 1- is effectively: OVER + SWAP SWAP 1-
That is rather redundant! In the next release of the novice-package I will have:
macro: backward-bounds ( adr cnt -- base-adr last-adr )
over + 1- ;
BACKWARD-BOUNDS still has the problem of not handling an empty string correctly --- so we are effectively back to the problem that Charles Moore had when he was using DO and before he invented ?DO (he likely felt dumb the first time that he tried to use DO on an empty string) --- I tried to use ?DO in BACKWARDS$ in string-stack.4th which was one of my bugs that I had to fix (I know I felt dumb!). It is embarrassing to make software public and then have to distribute a bug-fixed version --- at least I do fix the bugs though, whereas Forth Inc. requires another $300 from their paying customers to get the bug-fixed version of SwiftForth. MicroSoft does this with Windows though, which is presumably Elizabeth Rather's inspiration for selling SwiftForth with bugs and then charging extra for the bug-fixed version --- maybe she and Bill Gates can share a pit in Hell.
The biggest problem with DO is that it relies on tricky programming. DO loops rely on a trick involving the overflow flag that allows the same word DO to be used for going down and going up, although +LOOP has to be used for going down whereas it is optional when going up because LOOP is short-hand for 1 +LOOP. The problem with this tricky code is that the result is highly non-intuitive because the limit is equal to the last value when going down but is one more than the last value when going up. This is another example of exposing the implementation to the user but forcing the user to work with a weird behavior just to allow a tricky implementation to work. Another problem here is that not all processors have an overflow flag. The MiniForth didn't have an overflow flag, and the Stundurd doesn't either.
In summary: a major failing of ANS-Forth was that it standardized implementation gratuitously when it was supposed to only standardize behavior. Um, yeah!
[toc] | [prev] | [next] | [standalone]
| From | "WJ" <w_a_x_man@yahoo.com> |
|---|---|
| Date | 2016-03-26 22:11 +0000 |
| Message-ID | <nd71fb$b6v$1@dont-email.me> |
| In reply to | #46043 |
hughaguilar96@gmail.com wrote:
> : my-type ( adr cnt -- )
> over + swap ?do
> I c@ emit loop ;
> : my-backward-type ( adr cnt -- )
> over + 1-
> 2dup u< if
> do I c@ emit -1 +loop
> else
> 2drop then ;
OCaml:
let my_type string len =
for i = 0 to len - 1 do
print_char string.[i]
done ;;
# my_type "foo bar" 3;;
foo- : unit = ()
# my_type "foo bar" 0;;
- : unit = ()
let my_backward_type string len =
for i = len - 1 downto 0 do
print_char string.[i]
done ;;
# my_backward_type "foo bar" 3;;
oof- : unit = ()
# my_backward_type "foo bar" 0;;
- : unit = ()
> I don't blame the novice for abandoning
> ANS-Forth (I would too if I were 18 again,
> but it is too late for me now).
Some time ago, Paysan posted a link to a study that showed
that when older people learn new things, some brain cells
are killed or damaged.
It seems that vitamin D helps to protect the brain and
prevent dementia. (It helps the body in many other ways, also.)
About 7000 units per day is the currently recommended amount.
[toc] | [prev] | [next] | [standalone]
Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →
Back to top | Article view | comp.lang.forth
csiph-web