From: stephenb@harlequin.co.uk (Stephen J Bevan) Subject: Re: many errors in Forth for Windows Date: 26 Jul 1996 12:47:40 GMT Message-ID: References: <31E76314.2120@forth.com> <4t2fme$mma@life.ai.mit.edu> <4t2vmi$f16@hkusuc.hku.hk> <4tabre$8bb@iaehv.IAEhv.nl> In-reply-to: mhx@IAEhv.nl's message of 26 Jul 1996 13:57:34 +0200 In article <4tabre$8bb@iaehv.IAEhv.nl> mhx@IAEhv.nl (Marcel Hendrix) writes: > Certainly, if something as nice as Tcl/Tk can be done (by a non-commercial > developer), then much greater things can be done in Forth. I thought Ousterhout had a batallion of Sun programmers in the back (read the release notes)? The initial releases of Tcl/Tk were made when he was at Berkeley. From: hbaker@netcom.com (Henry Baker) Subject: Re: Stack Computer book on-line Message-ID: References: <31f61e27.6475492@usenet.interramp.com> Date: Fri, 26 Jul 1996 13:12:49 GMT In article , jvn@faraday.clas.Virginia.EDU (Julian V. Noble) wrote: > Thanks to Phil Koopman for putting his book on line. However, > as Cliff Stoll notes in "Silicon Snake Oil", on-line documents > are not as useful as hard copy ones. On the contrary: if Koopman's book is properly indexed by altavista, then I expect it to be much more valuable than it was in print. From: mhx@IAEhv.nl (Marcel Hendrix) Subject: Re: many errors in Forth for Windows Date: 26 Jul 1996 13:57:34 +0200 Message-ID: <4tabre$8bb@iaehv.IAEhv.nl> References: <31E76314.2120@forth.com> <4t2fme$mma@life.ai.mit.edu> <4t2vmi$f16@hkusuc.hku.hk> Ken Deboy wrote Re: many errors in Forth for Windows >Zsoter Andras writes: > >>If I go to the local bookstore I can buy a C book on whatever level >>for the equivalent of a few tens of US$, but Forth books do not even exist! Here in the Netherlands, any technical book in the original language (don't get me excited about the miserable quality of translations!) costs Dfl 100,- at least, which is around $60 (or 3 to 4 good-quality audio CD's :-)). This is several times the price Andras mentions. >> >>[Well I can order "Thinking Forth" from FIG, for about twice the above >>mentioned price, but that is it.] >> Which makes it about $60 and thus perfectly ok. >>The of-so-superior books about Forth >>are available only bundled with a compiler which is several times the >>price of a C, C++, or Pascal compiler. It seems C (and Pascal) is supported > This is absolutely correct. My Pascal compiler (purchased for a > CS class) cost me $97. My C++ compiler (also purchased for a CS > class) only cost $79. It included a GUI, a large library to > help me develope my own GUIs, an 800-# support line, printed > documentation, and many example programs, including a killer > chess program. Where is this in the Forth community? Last time I > looked at the ads in _Forth Dimensions_, the cheapest commercial > Forth I saw was $179, and it was based on the 79 Standard. You got an educational discount then? I paid around $500 to get BC++ 4.5. They wanted $100 extra for some extensions to compile 32-bits programs for DOS. And I bought it before Windows 95 came out, so now I have to buy it again for say $600? (and again for WinNT?). Or look at this way. That $179 Forth didn't come with 3000 pages of documentation (what I got with C++), so you saved 3000*5 minutes = 250 hours of reading at say $80/hour. So you could have saved $20,000 by doing it the Forth way. I tell yah about this get-rich-quick scheme of mine... The problem lies elsewhere. From the C-compiler I know what to expect, and I know it will do whatever I need to do with it. So I pay anything for it (up to some magic number which is probably $600 in my case). From the Forth compilers I don't know *anything* (show me a review!), and from experience in the past I could end up with a very weird system. In that case even $179 (2 hours of work) is too much to pay. [ flame deleted ] >>community. For many potential users the question is not whether or >>not to buy a commertial Forth, but whether go with VC++ (Borland C, >>Delphi, VB, you name it) or give a try to Win32Forth. >>To discourage such users is like saying "If you consider Forth >>you are obviously an idiot." If you have nothing to program, don't start with Forth. If you have something to program, choose the best tool for the job. If "best" has an economic aspect to it, I don't see why Forth is always the way to go, especially for mainstream applications. > Again, absolutely correct. I see many posts here from people > criticizing things they don't like about certain Forths. I say, > if you don't like it, then write something better! On the other > hand, I've noticed in other language groups that the people > there actually follow a standard (ANSI?) of the language they > like, and instead of spending their bandwidth criticizing the > features they don't like, they work around the limitations of > the standard. If you want forth to be popular, then develope > applications that work well _in spite of_ what you don't like > about ANSI Forth (or whatever the "standard" is). Very well put. This is in essence the "problem" with clf: it lets potential users think Forth is a compiler-writer's toy. Not something to attract the bright-eyed kids with (if they still exist). > Certainly, if something as nice as Tcl/Tk can be done (by a non-commercial > developer), then much greater things can be done in Forth. I thought Ousterhout had a batallion of Sun programmers in the back (read the release notes)? Tk is indeed very nice, especially because it offers a GUI that runs on more than one platform and is user-extensible. Ousterhout considered writing Tcl in Forth, but he did not know the language well enough to see that it was possible. Some academic interests may have been conflicting here too :-) > Ken Deboy -marcel From: koopman@cs.cmu.edu (Phil Koopman) Subject: Re: Stack Computer book on-line Date: Fri, 26 Jul 1996 11:59:58 GMT Message-ID: <31f8af09.1425358@usenet.interramp.com> References: <31f61e27.6475492@usenet.interramp.com> jvn@faraday.clas.Virginia.EDU (Julian V. Noble) wrote: >Re: the publisher "graciously returning Phil's copyright..." >one should note that most book contracts have a clause requiring >this as long as the book is not "in print". Yes, I did indeed have such a clause, but it allowed a 9-month waiting period for them to decide if the market supported a second edition/reprinting. They responded within a month of getting my letter, and were indeed gracious about the matter. >... on-line documents are not as useful as hard copy ones. That is a matter of opinion and debate. You can't find my hard-copy book by searching with Altavista, Lycos, Hotbot, etc. unless you get lucky with the words in the on-line abstract I had in place. (Eventually you will be able to find the on-line version with these once it is indexed.) I think that an on-line version will greatly increase availability, especially to casual readers who wouldn't bother with inter-library loan of what is a moderately difficult to locate book. I think it will also make it more readily available in places such as Russia, where my former publisher refused a translation opportunity because of the difficulty of turning a profit there a few years back. >Perhaps with enough interest Phil would let FIG reprint his book, Mountain View Press is working on it; see the on-line title page. MVP has a non-exclusive license, but I'd really be surprised if the market supported enough volume to make competition worthwhile. It will be interesting to see whether hard-copy sales increase or decrease as a result of web availability. -- Phil (follow-ups to comp.lang.forth) Phil Koopman -- koopman@cs.cmu.edu -- http://www.cs.cmu.edu/~koopman From: znmeb@teleport.com () Subject: Re: Is using mult Exits bad pgrming Date: 26 Jul 1996 15:24:23 GMT Message-ID: <4tanv7$bl7@nadine.teleport.com> References: <6DS5A4LGCHB@malente.forth-ev.de> <4t8sfd$cg4@nadine.teleport.com> <4t9qre$aoj@hkusuc.hku.hk> Zsoter Andras (h9290246@hkuxa.hku.hk) wrote: : znmeb@teleport.com wrote: : >1. Back when Julian Noble and I were young sprouts practicing the craft : > of scientific programming (Fortran II, three-branch IFs only :-), : > our business-programming brethren were happily structuring their : > software with something called decision tables. So while we were : > slaving away writing spaghetti code, which is all you can do with a : > three-branch IF and a DO-loop, the COBOL guys had this all figured : > out. : What is wrong with a three-branch-if? : I rather miss them in HLL-s (Assembly naturally works nearly that way). The only reason the three-branch IF was created is that the original target machine for FORTRAN, the IBM 704, had a compare instruction that branched three ways depending on a value being 0= 0< or 0> (sneaky -- I specified it in Forth :-). -- znmeb@teleport.com (M. Edward Borasky) http://www.teleport.com/~znmeb I support the right to keep and arm bears. From: mikc@gnu.ai.mit.edu (Mike Coughlin) Subject: Re: Is using mult Exits bad pgrming Date: 26 Jul 1996 13:56:27 GMT Message-ID: <4taiqb$hl2@life.ai.mit.edu> References: <4t8sfd$cg4@nadine.teleport.com> <4t9qre$aoj@hkusuc.hku.hk> In article <4t9qre$aoj@hkusuc.hku.hk>, Zsoter Andras wrote: >znmeb@teleport.com wrote: >>1. Back when Julian Noble and I were young sprouts practicing the craft >> of scientific programming (Fortran II, three-branch IFs only :-), >> our business-programming brethren were happily structuring their >> software with something called decision tables. So while we were >> slaving away writing spaghetti code, which is all you can do with a >> three-branch IF and a DO-loop, the COBOL guys had this all figured >> out. >What is wrong with a three-branch-if? >I rather miss them in HLL-s (Assembly naturally works nearly that way). The three branch if caused the most number of coding errors in the old days when I had to use it. The other big error generator was Fortran's automatic creation of new variables when I defined a variable by mistake and didn't set its value. As time went on, I got better at finding mistakes in variables, but I still had just as many problems with the three valued if statement. Assembly language programming is much more difficult than necessary since it uses so many things that the human mind cannot cope with. A good language like Forth removes sources of error by removing the methods that cause errors. -- Michael Coughlin mikc@gnu.ai.mit.edu Cambridge, MA USA From: "Bruce R. McFarling" Subject: Re: Is using mult Exits bad pgrming Date: 24 Jul 1996 00:31:34 GMT Message-ID: <4t3qt6$fcq@seagoon.newcastle.edu.au> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.2N (Windows; I; 16bit) To: jvn@faraday.clas.Virginia.EDU jvn@faraday.clas.Virginia.EDU (Julian V. Noble) wrote: >I could not agree more re: using a state machine generator. >I have given an ANS compatible version of my FSM mini-compiler >in an article that was supposed to have appeared in JFAR 2 >years ago (actually, an earlier version was to have appeared >_6_ years ago!). If there is general interest I will post the >code at taygeta, together with the article. Consider this one expression of interest. I hope you get enough to support a generalization. -- Virtually, Bruce R. McFarling, Newcastle, NSW ecbm@cc.newcastle.edu.au From: Bill Zimmerly Subject: Re: Manipulating Return Addresses Date: Fri, 26 Jul 1996 14:20:26 -0500 Message-ID: <31F91A7A.1B4B@inlink.com> References: <31F76F75.5E13@headwaters.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01Gold (WinNT; I) Brad Rodriguez wrote: [Snip] > I'm dismayed to see the argument so often offered, "I don't use that > programming technique, so it must not be of any value." The same > argument could be (has been!) offered for vocabularies, DOES>, local > variables, exception handling, memory allocation, and floating point... > to name a few. Yes, I can program without DOES>. But DOES> makes my > programs cleaner, smaller, and faster, so I'd fight to keep it. Likewise > with return stack manipulations. > > -- > Brad Rodriguez bj@headwaters.com Computers on the Small Scale > This brain for rent -- inquire within. > Contributing Editor, The Computer Journal... http://www.psyber.com/~tcj > Director, Forth Interest Group........... http://www.forth.org/fig.html Brad, you are SOOOOOOOO right! Forth would not be what it is had not Mr. Moore been dissatisfied with the status quo. If people want to stick with just what the compiler can currently do... ..then let them program in Cobol. To not be able to change *ANY* aspect of Forth...the behavior of any word/vocabulary/etc. is simply not Forth programming IMNSHO. "Dismayed" as well, - Bill -- \\\|/// \\ ~ ~ // (/ @ @ /) --------------oOOo-(_)-oOOo--------------------------- William B. Zimmerly (Bill) - Systems Research & Development Manager / Webmaster General American Life Insurance Company, Inc. Amateur Radio Call: KA0YKO Email Address: billz@inlink.com Home Page Address: www.inlink.com/~billz ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._ Message-ID: <10@brady.win-uk.net> Reply-To: stuart@brady.win-uk.net (Stuart Brady) From: stuart@brady.win-uk.net (Stuart Brady) Date: Fri, 26 Jul 1996 20:42:28 GMT Subject: Beginners Help.... Hello, I have decided to try and learn Forth and I am looking for advice. I have lurked around this echo before while making my mind up. i.e. Forth or another language. Visual Basic, C++ etc. I LIKE Forth. At the moment I have FPC Forth (v3.56) which seems good but I wonder if there is another Forth compiler etc I should be using. The FPC v3.56 I have been browsing came from the FPRIMER.ZIP made in 1992(?) which seems rather a long time ago now. One FPC question.... I set up a file [STUART1.SEQ that I wanted to FLOAD/INCLUDE/OPEN(OK) from STUART2.SEQ when it was FLOAD(ED)/INCLUDED etc. Wossamatta???? All the Beast Stuart stuart.brady@win-uk.net From: znmeb@teleport.com () Subject: Re: Multiple EXITs and structure Date: 26 Jul 1996 19:57:21 GMT Message-ID: <4tb7v1$hpm@nadine.teleport.com> References: Julian V. Noble (jvn@faraday.clas.Virginia.EDU) wrote: : jvn@faraday.clas.Virginia.EDU writes: : > "Good/Bad" programming is in the eye of the beholder. : > : > However, the virtues of a well-structured, readable and maintain- : > able program need not be repeated here. I have generally found : > the structure : > : > : choices cond_A IF do_A EXIT THEN : > cond_B IF do_B EXIT THEN : > ....... : > ; : > : > to be more readable than a bunch of nested IF...ELSE...THENs : > : > : choices' cond_A IF do_A ELSE : > cond_B IF do_B ELSE : > ....... : > THEN ... THEN : > ; : > : > which is also equivalent to the CASE...OF structure. : > : > Note, BTW, that they are not logically equivalent unless the : > conditions are mutually exclusive. That is, A and B can't be : > simultaneously true. This is a pitfall that probably has caused : > more program bugs than any other single source (including spaghetti : > code). : Doggone it! I knew there was something wrong with that when I : wrote it. What I _meant_ to say was, "Although they are logically : equivalent, they depend on the order of evaluation unless the : conditions are mutually exclusive." Sorry, it was late and I : was tired from (creatively) working on expense accounts. That's *exactly* why I like the Dijkstra guarded commands! An IF aborts if none of the conditions are true, so if your code hits a case you didn't plan for, you get informed and execution terminates! Let me summarize the structures, since I brought this up. A conditional is written if f1 ==> x1 | f2 ==> x2 | f3 ==> x3 | . . . fi This is read "if f1 is true then do x1, if f2 is true then do x2," etc. As I noted above if none of the conditions are true, the construct aborts. If more than one is true, the implementation selects one of them to execute in a manner not known to or controlled by the programmer. The corresponding loop is written do f1 ==> x1 | f2 ==> x2 | f3 ==> x3 | . . . od If none of the conditions is true, this becomes a no-operation. If one or more of the conditions is true, the implementation selects one of them in a manner not known to or controlled by the programmer, executes the corresponding action, then branches back to the "do" for another pass. The loop keeps going until none of the conditions is true. Here's a simple example: the GCD of two integers: do x > y ==> x := x - y | y > x ==> y := y - x od When x = y, the loop is done and both x and y are equal to the GCD of the original x and y! This looks like it would be easy to do in ANS Forth with "origs" and "dests". You'd have to rename DO and IF, of course, since they have defined uses already. I may get a chance to try this with hForth over the weekend; I'll post the code here if I do. -- znmeb@teleport.com (M. Edward Borasky) http://www.teleport.com/~znmeb Actually, for their size, elephants don't smell all that bad. "The only thing we have to fear is fear itself -- and, of course, the boogeyman." Pat Paulsen From: Tom Zimmer Subject: Re: many errors in Forth for Windows Date: Fri, 26 Jul 1996 15:24:31 -0500 Message-ID: <31F9297F.4434@austin.finnigan.com> References: <31E76314.2120@forth.com> <4t2fme$mma@life.ai.mit.edu> <4t2vmi$f16@hkusuc.hku.hk> <4tabre$8bb@iaehv.IAEhv.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Marcel Hendrix wrote: > > > Or look at this way. That $179 Forth didn't come with 3000 pages of > documentation (what I got with C++), so you saved 3000*5 minutes = > 250 hours of reading at say $80/hour. So you could have saved $20,000 by > doing it the Forth way. I tell yah about this get-rich-quick scheme of > mine... > I like your attitude. Write less documentation, the users make more money! Why didn't I think of that, Tom Zimmer From: Tom Zimmer Subject: Win32Forth Version 3.2 Released (long) Date: Fri, 26 Jul 1996 15:15:48 -0500 Message-ID: <31F92774.64AC@austin.finnigan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Hello all, I have just released Win32Forth version 3.2 It was uploaded to ftp://taygeta.com/pub/incoming as files; ftp://taygeta.com/pub/incoming/w32for32.exe ftp://taygeta.com/pub/incoming/w32for32.txt ftp://taygeta.com/pub/incoming/w32for32.faq ftp://taygeta.com/pub/incoming/w32for32.new I have asked Skip to put them on his Compiler page in place of version 3.1. Here is a list of the changes since somewhere after version 3.1 on May 1st till the present; July 26th, 1996 - 12:00 ********************* Release Version 3.2 ********************* July 23rd, 1996 - 17:04 tjz Found and fixed a bug in WinView that would cause a crash when opening binary files. Seems I was using the wrong polarity conditonal on the test that was used to expand the line pointer table size. This resulted in more or less continuous pointer table expansion until all computer memory was used up. Not good! FIXED July 22nd, 1996 - 16:47 tjz Tested compiling the wrapper in Microsoft Visual C++ 4.0b2. It seems to work without any changes. July 19th, 1996 - 9:10 tjz Received a bug report from Jih-tung Pai, that there was a stack error in the word UNLINK-MALLOC, which is used by FREE. He was correct, it has been corrected. Thank you Jih-tung Pai. July 18th, 1996 - 10:46 tjz Modified "FSAVE, so it won't allow saving to the currently executing program. Even though you could try to do this before, it would fail. Now it fails, but warns that you shouldn't even try to do that. Improved the implementation for C+PLACE. Suggested by Mihail Maksimov. July 16th, 1996 - 9:04 tjz Bernd reported that s" could only be used once interpretively, and if it was used a second time, would overwrite the first string. I added a a defered word NEW$ that allows forward referencing the NEW$ semi-static buffers implemented in POINTER.F. Modified S", C" and Z" to use NEW$ when interpreting. July 12th, 1996 - 9:40 tjz Moved CurrentMenu and CurrentPopup into the Window Class, making them local to each window, rather than having them be global. This was needed so that an application could have more than one window, and have a separate menubar and right mouse popup menu for each window defined in an application. This change will require an application change as shown in the following code segment. -------------------------- SETTING POPUPBAR --------------------------- The following lines were extracted from WINDEMO.F. NOTE: that several lines not relavent to this illustration have been removed to simplify the example code. ------------------------------------------------------------------------- :M Classinit: ( -- ) ClassInit: super \ self to CurrentWindow \ COMMENT OUT THIS LINE \ Demo-popup-Bar to CurrentPopup \ COMMENT OUT THIS LINE ;M :M On_Init: ( -- ) On_Init: super 2 SetId: vga-bit-window self Start: vga-bit-window \ self Start: CurrentPopup \ COMMENT OUT THIS LINE Demo-popup-Bar SetPopupBar: vga-bit-window \ ADD THIS LINE ;M ------------------------------------------------------------------------- MORE NOTES: WinDemo is an example of an application that has a window that contains a child window. The child window is the window into which drawing is done. When the right mouse button is pressed, it is located within the area of this vga-bit-window, so the SetPopupBar: method must be performed on the child window vga-bit-window. In an application that has several child windows, a separate right mouse popup menu can be installed for each child window in the application. This results in a much more flexible implementation. Moved several facilities into WINDOW.F; SetPopupBar: SetMenuBar: LoadMenu: Added to ClassInit: self to CurrentWindow Added to On_Close: Close: CurrentMenu These changes simplify applications that use menus and right mouse popup menus. All example programs that use these facilities have been updated; WINVIEW, WINDEMO ------------------------------------------------------------------------- July 11th, 1996 - 15:46 tjz Included a new version of Jim's assembler 486ASM.F, version 1.24. Jim fixed a couple of bugs. Made some modifications to the hyper text compiler to change the file recognition character from 249 to a TAB. The 249 character was causing problems with the extended character set support. Also enhanced the code to exclude comments in source from being hyper text compiled. Modified all occurances of 'MessageBox' in Win32Forth to put up a message dialog that is application modal. It was just too easy to attempt to invoke multiple instances of the same message dialog, which would then cause a crash when they were closed, because the message box handle would already be NULL. The only significant difference you will see, is that message dialogs now appear in the center of the screen instead of in the center of the application window. July 10th, 1996 - 14:41 tjz Made changes suggested by Marcos Cruz to allow extended character sets to be used with Win32Forth and WinView. I don't know if they are complete, or even absolutely functional, since I don't use anything other than American English, but I'm sure someone will tell me if there is a problem. Also added UPPER-CASE and new LOWER-CASE functions to WinView to use the Win32API calls CharUpperBuff and CharLowerBuff for case conversion. These should work properly for all countries. At least in theory. July 1st, 1996 - 11:12 tjz Made some minor adjustments to DC.F and WINVIEW.F to correct problems with the way WinView printed text containing underscores on A4 (A5?) paper. It was truncating them, making them invisible. Not good. FIXED I think. June 28th, 1996 - 12:14 tjz Corrected a bug in OPTIMIZE, in file OPTIMIZE.F. I was optimizing away 'POP EBX' followed by 'PUSH EBX'. This is bad! Need to replace them with the instruction; 'MOV EBX, 0 [ESP]'. FIXED June 27th, 1996 - 10:51 tjz Renamed MAKEDLL.F to FORTHDLL.F to be more consistent with the other example files used in the FORTHDLL. Updates several of these files and added some new one. The list is something like this; --- Forth FORTHDLL.DLL Application Creation Files --- MESSAGES.F loaded first onto Win32Forth, defines message support, and the facility to define callable DLL subfunctions. FORTHDLL.F loaded after your application. Saves the Forth Image as a resource in FORTHDLL.DLL, and automatically builds MESSAGES.H and MESSAGES.BAS which are used to interface to the FORTHDLL.DLL from Visual C or Visual Basic. --- Visual C FORTHDLL.DLL Wrapper Project Files --- FORTHDLL.MAK Visual C project file to build the DLL wrapper. You must compile this with Visual C before doing anything with Win32Forth to make a DLL. FORTHDLL.DEF File needed to build FORTHDLL.DLL FORTHDLL.RC File needed to build FORTHDLL.DLL FORTH.C File needed to build FORTHDLL.DLL TERM.C File needed to build FORTHDLL.DLL FORTH.ICO File needed to build FORTHDLL.DLL ICON1.C File needed to build FORTHDLL.DLL FORTH.H File needed to build FORTHDLL.DLL TERM.H File needed to build FORTHDLL.DLL --- Visual C FORTHDLL.DLL Access Files --- FORTHDLL.H The automatically generated message constant file that would be included in a Visual C project file that wanted to access the FORTHDLL.DLL. No project for Visual C is provided, only the following Visual Basic demo program following. --- Visual Basic FORTHDLL.DLL Access Files --- FORTHDLL.VBP Visual Basic project file to demonstrate calling FORTHDLL.DLL. MESSAGES.BAS The automatically generated message constant file that must be included in your Visual Basic project file. FORTHDLL.BAS Demonstration Visual Basic source file that contains the interface to the FORTHDLL entry point. Making a DLL requires the following steps; 1. Build the FORTHDLL.DLL with Visual C. 2. Edit and compile your DLL application including MESSAGES.F at the beginning nd FORTHDLL.F at the end. DLL entry points are defined with the :DLLFunc subfunction defining word. After compiling FORTHDLL.F, the DLL FORTHDLL.DLL will have been updated with your applications Forth Image. 3. Edit and compile the Visual Basic FORTHDLL.BAS file to include the :DLLFunc subfunctions you added to FORTHDLL.DLL. 4. Debug and iterate on steps 2 through 4 until you application works the way you want it to. 5. Save the compiled Visual Basic program as an EXE. 6. Run the Visual Basic EXE, and you are done. 7. Distribute the DLL. Added another form of optimizing to OPTIMIZE.F. It code compiles inline any simple colon definitions is finds while optimizing. That is it looks inside any colon definition it finds, and if the colon definition contains only optimizable words, then the definition is inlined with optimization rather than switching back to high level code and compiling a threaded call. June 26th, 1996 - 10:54 tjz Added additional word documentation to FKERNEL.F. June 25th, 1996 - 12:46 tjz Several people found that there were open file problems when starting WinView with the "reopen same file as last session" button option selected. This was caused by a bug in the Registry Get Key function. I was using a local string buffer that was getting deallocated before it was being used. FIXED Also fixed some problems related to automatically saving edit changes. June 24th, 1996 - 14:55 tjz Added additional optimizations as suggested by; "Maksimov M.O." mak@xperts.rtc.neva.ru He found that a bunch of kernel code words begin with "PUSH EBX" and end with "POP EBX". These pairs can be optimized out of existence. June 10th, 1996 - 11:20 tjz Got rid of the EXCEPTIONS vocabulary, moved its few words into HIDDEN. Moved Registry support lower in the load order. June 7th, 1996 - 11:22 tjz Added several Pinhole optimizers to OPTIMIZE.F. It now looks for literals to preceed words like +, -, AND, OR, XOR, !, +!, C!, C+!, LSHIFT, RSHIFT and +TO. When these are found, it compiles an instruction that contains the preceeding literal, saving several bytes. These optimizers recover most of the extra space consumed by simply turning on the optimizer and laying code down inline right out of the kernel. June 5th, 1996 - 9:47 tjz Fixed several bugs in OPTIMIZE.F. I have been able to compile the entire WinView Editor in optimize mode, and have the resulting executable runable. This is not however something I would normally want to do, since the resulting program is about twice as big as the un-optimized program. The optimizer is for speed, and as such should only be used on program code sections that need to be faster, not entire programs. Also received a bug report from Ribert Smith. He found that the print dialog in WinView wouldn't come up for user selection after the first time you printed. This was a bug in the wrapper relating to the way I was initializing the printer. FIXED NOTE: The Print button in Winview is designed to display the print dialog only the first time you go to print. If you have already printed at least one page, then the printer button on the toolbar just goes ahead and prints. If you want to select parameters other than the ones used last time you printed, then you need to use the "Print File..." menu item under the File menu. At the suggestion of Robert Smith, I also added an option in the WinView preverences dialog to turn off the printing of page borders. Currently this also diables the printing of the footer date, and page numbers. Munroe C. Clayton and others reported a bug in F** and FEXP in the floating point. I passed the report on to Robert Smith, and he supplied information that his original testing was done on another assembler. Subsequent testing determined that the code generated by the earlier assembler for the instructions FSUB and FSUBR was reversed. This was effecting the assembly functions FEXP and FEXPM1. These are used in various floating point operators. I determined with Andrew's help that Jim's assembler was generating correct instructions, but the floating point code had been adjusted to produce correct code with the previous assemblers reversed instructions. I corrected FLOAT.F to account for Jim's assembler being correct. I hope this fixes the problems, but I will have to wait for further feedback and verification. June 3rd, 1996 - 13:46 tjz Made TempRect into an object of class Rectangle. This will have a significant impact on any application code that uses the word TempRect. The new object TempRect is defined at the end of CLASS.F, and provides methods for setting, erasing and displaying the fields of the rectangle. Usage of TempRect is much cleaner than before, but it is quite different, so you will want to look as how it is used in the various places in Win32Forth for examples of how it is now used. Here is an overview; Old way \ init TempRect and return x y 'x 'y TempRect dup>r \ its address r@ hdc Call GetClientRect ?win-error \ call windows with rect r@ 2 cells+ @ ( -- n1 ) \ get the "right" field of rect r> DeleteRect \ erase TempRect after use New Way x y 'x 'y SetRect: TempRect \ init TempRect TempRect.AddrOf hdc Call GetClientRect \ call window with rect TempRect.Right ( -- n1 ) \ get the "right" field of rect EraseRect: TempRect \ erase TempRect after use As you can see it certainly is quite different. I think it is also much more readable than before. While the Old way appears to have been reentrant, in reality there was really only one TempBuf, which was re-used each time TempRect was referenced. WARNING: I have found that the DOTTED '.' notation cannot be used on dynamically created objects. This is because there is no way currently to determine at compile-time which class the object refers to. This is inconvenient in the cases similar to the above where you might like to create a rectangle dynamically and then dispose of it after use. May 31st, 1996 - 13:24 tjz Modified the way the menu and toolbar words work. Added a new word that must be used to complete the definitions of any of the "BAR" words, such as MENUBAR, TOOLBAR, POPUPBAR etc.. All of these bar defining words should be completed with the word ENDBAR. This change allows the lower level utility words that are used in building the various bars to be hidden except when they are needed, reducing the number of functions dumped in the Forth vocabulary by a significant number. Here is an extract from the example program WINDEMO.F that illustrates the use of ENDBAR. POPUPBAR Demo-Popup-bar POPUP " " MENUITEM "Open File..." 'O' +k_control pushkey ; MENUSEPARATOR MENUITEM "Print File..." 'P' +k_control pushkey ; MENUSEPARATOR MENUITEM "Exit" bye ; ENDBAR May 30th, 1996 - 18:09 tjz Added a file MODULE.F to Win32Forth. A simple implementation for function scoping, used in the form; INTERNAL \ internal definitions start here ... define the internal definitions ... EXTERNAL \ externally available definitions start here ... define the definitions you want to be available externally ... MODULE \ finish up the module. There are other implementations, but this was one I liked from way back. Internal definitions are automatically placed in the HIDDEN vocabulary, so they can be obtained later if needed. May 29th, 1996 - 10:05 tjz Moved CLASS.F down lower in the load order to make OOP available earlier in the extend process. May 24th, 1996 - 12:10 tjz Moved the local variable support down into the kernel. No support by the meta compiler, but at least local variables can now be used as soon as the kernel starts up. May 23rd, 1996 - 15:48 tjz Modified the Control-L (load highlighted text) command in WinView to feed the highlighted text through the Win32Forth keyboard macro mechanism rather than feeding it through a file called TEMP.F. The way it now works, is WinView simply does a text copy to the clipboard of the highlighted text, then tells forth to perform a paste and load, which causes the text in the clipboard to be entered through the keyboard. Also added a Paste function in the new Edit menu to Win32Forth. May 22nd, 1996 - 14:47 tjz Added some more instructional sections about objects to STARTUP.TXT. Re-inserted 'DINT' as an object data type, so it could be used in the directory continguous data structure example in STARTUP.TXT. May 21st, 1996 - 9:19 tjz Added the words to support dynamic objects as follows; HEAP> ( -- ) allocate and init an object of "classname" NEW> ( -- ) synonym for HEAP>, more C++ like DISPOSE ( a1 -- ) dispose of object a1 after executing the default distructor method "~:" ~: the default object destructor method Dynamically allocated objects are initialized using the ClassInit: method, just like any other instance of a class. When you are done using the object, you can dispose of its instance by passing its address to DISPOSE, which will execute the destructor method "~:" and then release the memory space used by the object. Moved the hashed dictionary code out of PRIMUTIL, down into the kernel and meta compiler. Moved N(FIND) down into the kernel, and renamed it to (FIND), eliminating the old (FIND) from the kernel. There used to be a word called HASH, that was only used by the Object code, and another word called "#HASH that was used by the Forth system for headers and dictionary searches. I have renamed HASH to METHOD-HASH, to avoid someone thinking the two hashes are the same, they are not. May 20th, 1996 - 15:02 tjz Revamped memory allocation and deallocaton. Dynamic memory that is allocated by a program will now automatically get released, even if you don't release it. This functionality is built into ALLOCATE, MALLOC, FREE, REALLOC, RELEASE, and RESIZE, as well as POINTERs. A side effect of this modification, is that FREE which previously returned a dummy FLASE flag, because no FREE could fail, now validates the pointer about to be freed, and will return a TRUE (failure) flag if the pointer isn't on the list of valid memory pointers. The word RELEASE which used to just discard the dummy flag, now checks the flag, and performs an abort if the FREE fails. The side effect of this, is that you need to use FREE instead of RELEASE if you want to handle errors yourself. May 17th, 1996 - 14:44 tjz Additional changes to CLASS.F, to add a pair of words RECORD: and ;RECORD to tell the compiler to force all data objects defined INSIDE A CLASS between these words to be contiguous, and to define a data object that doesn't consume any space, but returns the address of the start of the record. They are used as follows; :Class Point \TEMP.F and then WinView tells Win32Forth to perform an FLOAD \TEMP.F. NOTE: Due to thread prioprity problems, you may need to move the mouse over the Win32Forth console window to allow it to get some execution priority so the highlighted text will actually be loaded. Adde the additional debugger commands to the Edit menu as; Control+B set breakpoint and open debug window Control+D just open the debug window From: Tom Zimmer Subject: Re: Is using mult Exits bad pgrming Date: Fri, 26 Jul 1996 15:20:10 -0500 Message-ID: <31F9287A.31A4@austin.finnigan.com> References: <4r2c5p$o89@hkusuc.hku.hk> <4r2jqi$km3@newsbf02.news.aol.com> <4svcq7$pmo@hkusuc.hku.hk> <4t1s37$9dk@seagoon.newcastle.edu.au> <4t2c13$t6h@hkusuc.hku.hk> <31F4DE5C.3A34@ix.netcom.com> <31F6EFF8.2BC0@tir.com> <31F78C1B.1EED@ix.netcom.com> <31F87177.32AB@ix.netcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Richard Astle wrote: > > By the way, when did it become fashionable to make Forths case insensitive? > It has always been popular with me. I can never remember what the right case for a word is. I do however often use mixed case when I enter words for readability, but not findability. Tom Zimmer From: Tom Zimmer Subject: Win32Forth Version 3.2 Released (short version) Date: Fri, 26 Jul 1996 15:27:45 -0500 Message-ID: <31F92A41.6609@austin.finnigan.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Hello all, I have just released Win32Forth version 3.2 It was uploaded to ftp://taygeta.com/pub/incoming as files; ftp://taygeta.com/pub/incoming/w32for32.exe ftp://taygeta.com/pub/incoming/w32for32.txt ftp://taygeta.com/pub/incoming/w32for32.faq ftp://taygeta.com/pub/incoming/w32for32.new I have asked Skip to put them on his Compiler page in place of version 3.1. Here is a list of the changes since somewhere after version 3.1 on May 1st till the present; The long version of this message has the above mentioned notes in it. From: jvn@faraday.clas.Virginia.EDU (Julian V. Noble) Subject: Re: Is using mult Exits bad pgrming X-Nntp-Posting-Host: faraday.clas.virginia.edu Message-ID: References: <4t8sfd$cg4@nadine.teleport.com> Date: Fri, 26 Jul 1996 19:45:56 GMT znmeb@teleport.com writes: [ previous deleted ] > It looks like it's time for me to jump in here and throw a few more > irons into this fire: > > 1. Back when Julian Noble and I were young sprouts practicing the craft > of scientific programming (Fortran II, three-branch IFs only :-), > our business-programming brethren were happily structuring their > software with something called decision tables. So while we were > slaving away writing spaghetti code, which is all you can do with a > three-branch IF and a DO-loop, the COBOL guys had this all figured > out. [ point # 2 on deleted ] Noble's response to Point #1 above: Sorry to differ. But FORTRAN II contained both assigned and computed GOTO's, which are perfectly adequate to implement a decision table: SUBROUTINE FSM(ICOL) COMMON ISTATE C C THIS IS A STATE MACHINE, A SPECIAL CASE OF A DECISION TABLE C USING COMPUTED GOTO. C C THE STATE VARIABLE IS KEPT IN COMMON STORAGE C GOTO (1,2,3,4,5,6), ICOL+ISTATE+ISTATE C C THERE ARE 2 STATES, ISTATE=0 OR 1 C AND 3 COLUMNS, ICOL=1,2,3 IN THE STATE TABLE C 1 CALL ACTION1 ISTATE = ? RETURN 2 CALL ACTION2 ISTATE = ? RETURN C C ETC. C 6 CALL ACTION6 ISTATE = ? RETURN END Note that BASIC has a similar construct, ON expression GOTO linelist The real virtue of Forth (and my approach therein) becomes apparent when one wishes to construct more than one decision table or state machine. The other virtue is plain readability, since a state machine constructed by compiling its tabular representation is self-documenting. Finally I should note that Glen Haydon says my FSM paper is going to appear in the electronic version of JFAR, which will appear at a URL that I have been sworn not to reveal yet. (I know nothing whatsoever about the electronic version of JFAR, which is a bit surprising since I could have sworn that I have been a member of its editorial board since 1992 or 1993. But that's how these things go sometimes...) -- Julian V. Noble jvn@virginia.edu From: Tom Zimmer Subject: Re: Beginners Help.... Date: Fri, 26 Jul 1996 15:40:36 -0500 Message-ID: <31F92D44.6228@austin.finnigan.com> References: <10@brady.win-uk.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (WinNT; I) Stuart Brady wrote: > > Hello, > > I have decided to try and learn Forth and I am looking for advice. > I have lurked around this echo before while making my mind up. i.e. > Forth or another language. Visual Basic, C++ etc. > > I LIKE Forth. At the moment I have FPC Forth (v3.56) which seems > good but I wonder if there is another Forth compiler etc I should > be using. The FPC v3.56 I have been browsing came from the > FPRIMER.ZIP made in 1992(?) which seems rather a long time ago > now. F-PC is still a perfectly valid starter system for the DOS environment. If you are using Windows95, or WindowsNT, then you can try Win32Forth. Unfortunately Win32Forth has very little documentation, and won't really help you get started very well. Also, the Windows operating system adds quite a lot to the complexity of learning how to program, in Forth or any other language. There are also other Forths available for DOS, from: http://taygeta.com/forth.html Commercial systems are also available from Forth Inc. at; http://www.forth.com > One FPC question.... > > I set up a file [STUART1.SEQ that I wanted to > FLOAD/INCLUDE/OPEN(OK) from STUART2.SEQ when it was > FLOAD(ED)/INCLUDED etc. You can use FLOAD within a file that is already FLOADing, without any problem. I think you can even do that upto (or downto) about six nested levels. So, just put; FLOAD STUART1.SEQ Inside the file: STUART2.SEQ, and it will be loaded when tha appropriate line containing the above mentioned FLOAD is encountered. Tom Zimmer From: clodius@hotspec.lanl.gov (William Clodius) Subject: Re: multiple entries Date: 26 Jul 1996 13:46:18 -0600 Message-ID: References: In-reply-to: jvn@faraday.clas.Virginia.EDU's message of Fri, 26 Jul 1996 00:42:11 GMT Some flavors of FORTRAN, as I recall, allowed multiple entries to subroutines, each with its own name. This was an echo of the underlying assembler that permitted overlapping code sequences. This is certainly part of FORTRAN 77 and subsequent standards. I believe it was also part of the FORTRAN 66 standard, which suggests that it was first implemented in FORTRAN II, because FORTRAN I did not have subroutines. It does have maintenance problems partly because it is so rarely used, and partly because changes in earlier parts of the enclosing procedure can have unexpected effects on the code within the ENTRY. -- William B. Clodius Phone: (505)-665-9370 Los Alamos National Laboratory Email: wclodius@lanl.gov Los Alamos, NM 87545 From: "Paul E. Bennett" Subject: Re: Thanks! Got Job. Date: Sun, 21 Jul 96 22:47:36 GMT Message-ID: <837989256snz@tcontec.demon.co.uk> References: <4su2qs$n6j@nnrp1.news.primenet.com> Reply-To: peb@transcontech.co.uk X-NNTP-Posting-Host: tcontec.demon.co.uk X-Mail2News-Path: tcontec.demon.co.uk In article <4su2qs$n6j@nnrp1.news.primenet.com> mfiring@primenet.com "Martel Firing" writes: > Thanks to this newsgroup I got a FORTH programming assignment described > here a few months ago. > > Just wanted to acknowledge the good work of whoever runs this group and > thank them and the other participants. BTW, where is this newsgroup > originated? > > Sincerely, > Martel Firing You're not the only one Martel. My current consultancy assignment is also very heavily Forth related thanks to items in this newsgroup. The consultancy also uses most of my other knowledge and skills which when blended with Forth is very pleasing. I support the call for "Cheers" to all who have helped. -- Paul E. Bennett Transport Control Technology Ltd. Tel: +44 (0)117-9499861 Going Forth Safely From: John Ahlstrom Subject: Out of Print Classic Computer Arch Books On-Line (Was Stack Computer book on-line) Date: Fri, 26 Jul 1996 09:21:40 -0700 Message-ID: <31F8F094.5993@cisco.com> References: <31f61e27.6475492@usenet.interramp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (WinNT; I) Phil Koopman wrote: > > My stack computer architecture book has recently gone out of print, > but I still receive occasional inquiries as to availability. The > former publisher, Ellis Horwood Ltd., has graciously returned the > copyright ownership to me. So, I have decided to place the book > on-line at: > http://www.cs.cmu.edu/~koopman/stack_computers/index.html > -- snip snip > Happy reading! > -- Phil Koopman > > Phil Koopman -- koopman@cs.cmu.edu -- http://www.cs.cmu.edu/~koopman It seems that there are several classic, irreplaceable comp arch books out of print, e.g. Bucholz's Stretch book Thornton's 6600 book Organik's Multics book Wulf's Compiler Optimization and Hydra books Is there any way that we can get the copyrights returned to their authors and then figure out how to get them on-line? Is there any way we can get Dover permission to reprint them? What others ought to be made available in one of these ways? John Ahlstrom JAhlstrom@Cisco.com Any system of neural organization sufficiently complex to generate the axioms of arithmetic is too complex to be understood by itself. Kaekel's Conjecture From: root@pacx.com (root) Subject: Re: What is a fourth generation? Date: 27 Jul 1996 00:41:15 GMT Message-ID: <4tbojb$617@news.wco.com> References: I suppose Jeff that its first job its meaning the F*F compiler that is will be to punctuate english sentences at least inasmuch as to make them not seem like run on sentences but that will be a difficult challenge however the clarity that may result from just using hyphens to join words that together form adjectives may make the task at least worthwhile. forth heart if honk then jgray@pacx.com Jeff Fox (jfox@netcom.com) wrote: : In article <31c5d419.0@news.gamewood.net> : wilsonpm@gamewood.net (Pete M. Wilson) writes: ------------SNIP-----8<-----SNIP------------- : >Query language and report writers are also fourth-generation : >languages. Any computer language with English-like commands that : >doesn't require traditional input-process-output logic falls into this : >category. : Yes, this is the common use of fourth-generation. I have : always thought of these as specialized application specific : scripting languages. Like those that come with databases. : Of course Forth is very good for creating specialized : appication specific scripting languages. : >Fifth-generation languages are generally considered AI/logic-based : >languages that don't require a programmer to tell how to do an : >operation, but rather specify what the desired result is - hence the : >Japanse fifth-generation project based around Prolog, etc a few (ten?) : >years ago. : Yes. Edward Feigenbaum's book "the Fifth Generation" is the : definitive reference on the Japanese national fifth-gen project. : I think of the F21 microprocessor as 5th generation hardware. It is : designed for expert systems and simulated neural nets in a scalable : environment capable of running many ai programs efficiently in : parallel at a very low cost. The F*F compiler will be our low : level tool to compile optimized parallelized machine code for the : scalable systems from Forth and specialized application specific : scripting tools. Thanks in part to the language extension "Linda" : and Dr. Michael Montvelishsky's Parallel Channel compiler. : Under top level expert systems will be lower level more general : expert system problem solving resources thanks in part to the : Brad Rodriguez's TexMex (Threaded Execution Micro Expert) and : a variety of low level neural based recognition and reflex tools. : We should be able to load expert system rulebases and let the : software tune neural nets to simulate automatic machine learning. : I plan a logic module based on Laws of Form that will be used by : language and other expert systems. Near the top several expert : systems will compete for control in a form of subsumptive architecture. : The design is Rodney Brook's subsumptive reflex robots and Marvin Minsky's : concept of the society of mind being the competition and : cooperation of a relatively small number of agents running in a very : parallel environment. : That is my defintion for _a_ 5th generation system in development. : Jeff Fox From: root@pacx.com (root) Subject: FORTH and TCP/IP Date: 27 Jul 1996 00:51:01 GMT Message-ID: <4tbp5l$617@news.wco.com> Gentlemen: I am curious -- Has there been a TCP/IP kernel implemented in/with/for FORTH? My familiarity with the Language (from years ago) leads me to believe that FORTH and TCP/IP would be a rather useful combination. awaiting comments. All flames forwarded to packet multipliers. jgray@pacx.com Date: 26 Jul 1996 20:36:00 +0100 From: michael@malente.forth-ev.de (Michael Kalus) Message-ID: <6D_5iNklCHB@malente.forth-ev.de> References: Subject: Re: IF..ELSE..THEN *is* natural X-Charset: ISO-8859-1 ## Originalempfaenger: /comp/lang/forth Well, the IF..ELSE..THEN thread has come to rest. The "HOLY WAR was fun to whatch" (John O Comeau)... But then I went back to studied THE BOOK (Leo Brodie, 1984, "Thinking Forth"), and there was this headake again: Unresolved Marks, Questionmarks? M.L. Gassanenko wrote: > "Suddenly I have come to understanding that the Forth IF..ELSE.. >THEN syntax is quite natural, and, probably, THEN is the best word >to be in that place: > >: FOO ( n -- ) > dup 0< 0= \ If n is positive or 0, > if 200 + \ add 200, > else -200 + \ else add -200. > then . ; \ Then, print the result. >(...) >So, Forth THEN means 'after that'. >(...) >How can native speakers comment this?" Leo Brodie wrote: "A name should express 'what' is happening, not 'how' this is done." If we use this rule on IF...ELSE...THEN we find - IF does not realy tell us what is happening there, but does hide how it is done. - ELSE is telling us to proceede here if the test failes, and it does hide how it is done too. So its OK to Leo. - THEN does not tell us at all what is happening here. But it also hides how this is done. M.L.G then wrote: >The Concise Oxford Dictionary says: > >then [@en] adv., adj., & n. --adv. >_1 at that time; at the time in question (...). >_2 _a next, afterwards; after that (then he told me to come in). > _b and also (then, there are the childen to consider). > _c after all (it is a problem, but then that is what we are here for). >_3 _a in that case; therefore; it follows that (...). > _b if what you say is true (...) > _c (...) if you must have it so (...) > _d used parenthetically to resume a narrative etc. (...). >--adj. that or who was such at the time in question (the then Duke). >--n. that time (until then). > >(...)" *What* does THEN do? It resolves a forward reference in a structured conditional branch definition, doesn't it? So to my feeling of the english language I would use definition _1 "at that time" to interprete THEN. IF THEN But when I saw this, I felt even stronger it shoud be: IF RESOLVE We could eliminate THEN then. *Is* Forth one of those languages not realy using a THEN in structured conditional branching? Yours sincerly Michael Kalus Grüße aus Bad Malente, Michael ## CrossPoint v3.02 ## From: Bill Zimmerly Subject: Re: many errors in Forth for Windows Date: Tue, 23 Jul 1996 17:12:32 -0500 Message-ID: <31F54E50.265A@inlink.com> References: <4sqojj$gqa@life.ai.mit.edu> <4svpqo$svp@newsbf02.news.aol.com> <31F39513.3B60@austin.finnigan.com> <31F54D0C.2C16@inlink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01Gold (WinNT; I) Bill Zimmerly wrote: > > Tom Zimmer wrote: > > > > CRepublic wrote: > > > > > > I agree, I would love to see a simple Forth for Windows to english > > > dictionary. A forth word how it's used and what it does i.e. > > > > > > :M used to do such and such. puts shuch and such someplace. > > > M; Ends a :M structure def see :M > > > > > > I think somthing like that would be grate. Of corse with over 5000 > > > words in Win32Fourth it might also be something of a job. > > > > This seems like a good place to point out that much of what is in Win32Forth > > can (I say can) be infered to be documented by usage. In fact, that is how > > I remember how various pieces of Win32Forth work. By looking at my own or > > other peoples uses of the words in the system, I am able to deduce how to use > > most anything I find there. You might ask, how can I find these uses of > > words in Win32Forth. The answer is to use the search capabilities built into > > the WinView editor (or your own editor) to search multiple files (*.F) for > > occurances of the desired function. > > > > Now it is true, that this is only one way of learning a large complex system. > > It happens to be the way I prefer to learn, and it may not be the way you > > prefer to learn. So, it is also reasonable to say the Win32Forth is either > > not documented at all, or completely documented. It depends on how you > > prefer to learn, and how much time you are willing to spend in the process. > > I would argue, Tom, that your method is the *BEST* method because most of the definitions are very > short, well-factored, and of THE utmost importance...THEY ARE READABLE BY BOTH MACHINE AND MAN. The > fact is, this method gives the programmer the most complete and up-to-date knowledge about the > system being studied. > > Other methods seem to advocate dual-development of programmer/system documentation and it seems > natural, to me at least, that there would be a lag between the two. In short, "Code Rules Dude!" > > > > If you are a person that perfers to learn by reading documentation, then you > > may well be better off spending your money on a commercial documented > > system. I would hasten to point out however, that while learning by reading > > may be faster than learning by exploration, in the case of the Windows > > operating system, the amount to be learned is truely enourmous. If you think > > Win32Forth's 5000 plus words are a lot, you haven't seen anything yet. > > > > As Rebok (I think) says; Just DOIT! > > > > Tom Zimmer > > I've found the Win32For system to be *tremendous* and invite others in the WWW community to check > out some of the Web programs (written in Win32For) that I've been working on... > > A Calendar of > Events
*** Problem *** My inexperience in Newsgroup posting is showing!!! I'm not quite sure why I couldn't see the "Schedule App" above...the ",GaEvents.CAL" portion of the system should have been part of the link and "Schedule.NET" won't display without it...bummer. Oh well...this is how we *get* experience...at least the Mortgage.NET applet works since it doesn't need a data file! Sorry folks, :-( - Bill -- \\\|/// \\ ~ ~ // (/ @ @ /) --------------oOOo-(_)-oOOo--------------------------- William B. Zimmerly (Bill) - Systems Research & Development Manager / Webmaster General American Life Insurance Company, Inc. Amateur Radio Call: KA0YKO Email Address: billz@inlink.com Home Page Address: www.inlink.com/~billz ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._ From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: many errors in Forth for Windows Date: 27 Jul 1996 09:37:38 GMT Message-ID: <4tco12$mf9@hkusuc.hku.hk> References: <31E76314.2120@forth.com> <4t2fme$mma@life.ai.mit.edu> <4t2vmi$f16@hkusuc.hku.hk> <4tabre$8bb@iaehv.IAEhv.nl> Marcel Hendrix (mhx@IAEhv.nl) wrote: >Ken Deboy wrote Re: many errors in Forth for Windows >>Zsoter Andras writes: >> >>>If I go to the local bookstore I can buy a C book on whatever level >>>for the equivalent of a few tens of US$, but Forth books do not even exist! >Here in the Netherlands, any technical book in the original language (don't >get me excited about the miserable quality of translations!) costs Dfl 100,- >at least, which is around $60 (or 3 to 4 good-quality audio CD's :-)). >This is several times the price Andras mentions. Here we have international editions of virtually anything which can be used as a texbook, usually at a <= US$ 30 price (below 20 is not unusual!). However, Forth books are not even available in any bookstory in Hong Kong, but I can choose from at least 20 different C++ books at almost any store. >Or look at this way. That $179 Forth didn't come with 3000 pages of >documentation (what I got with C++), so you saved 3000*5 minutes = >250 hours of reading at say $80/hour. So you could have saved $20,000 by >doing it the Forth way. I tell yah about this get-rich-quick scheme of >mine... I think you have intended to be ironic here, but often a 200 pages long book is more valuable than a 2000 pages long one for the very reason you have just mentioned here. Andras From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Is using mult Exits bad pgrming Date: 27 Jul 1996 09:23:22 GMT Message-ID: <4tcn6a$mf9@hkusuc.hku.hk> References: <4t8sfd$cg4@nadine.teleport.com> <4t9qre$aoj@hkusuc.hku.hk> <4taiqb$hl2@life.ai.mit.edu> Mike Coughlin (mikc@gnu.ai.mit.edu) wrote: > Assembly language programming is much more difficult than >necessary since it uses so many things that the human mind >cannot cope with. A good language like Forth removes sources >of error by removing the methods that cause errors. A gun which refuses to assist you to shoot yourself on the foot? ;-) Andras From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Is using mult Exits bad pgrming Date: 27 Jul 1996 09:28:08 GMT Message-ID: <4tcnf8$mf9@hkusuc.hku.hk> References: <4r2c5p$o89@hkusuc.hku.hk> <4r2jqi$km3@newsbf02.news.aol.com> <4svcq7$pmo@hkusuc.hku.hk> <4t1s37$9dk@seagoon.newcastle.edu.au> <4t2c13$t6h@hkusuc.hku.hk> <31F4DE5C.3A34@ix.netcom.com> <31F6EFF8.2BC0@tir.com> <31F78C1B.1EED@ix.netcom.com> <31F87177.32AB@ix.netcom.com> <31F9287A.31A4@austin.finnigan.com> Tom Zimmer (tzimmer@austin.finnigan.com) wrote: >Richard Astle wrote: >> >> By the way, when did it become fashionable to make Forths case insensitive? >> >It has always been popular with me. I can never remember what the right >case for a word is. I do however often use mixed case when I enter words >for readability, but not findability. The same with me. Mixed case spelling makes sources a lot more readable: DeleteArray instead of DELETEARRAY , deletearray or delete_array (the latter one is C-ish). On the other hand when I communicate with my Forth interactively I don't want it to refuse if I type in something spelled in the wrong case (would be very inconvenient when I do something in a hurry) so I prefer case-insetive Forth. Andras From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: multiple entries Date: 27 Jul 1996 09:40:38 GMT Message-ID: <4tco6m$mf9@hkusuc.hku.hk> References: William Clodius (clodius@hotspec.lanl.gov) wrote: > Some flavors of FORTRAN, as I recall, allowed multiple entries > to subroutines, each with its own name. This was an echo of the > underlying assembler that permitted overlapping code sequences. >This is certainly part of FORTRAN 77 and subsequent standards. I >believe it was also part of the FORTRAN 66 standard, which suggests >that it was first implemented in FORTRAN II, because FORTRAN I did not >have subroutines. It does have maintenance problems partly because it >is so rarely used, and partly because changes in earlier parts of the >enclosing procedure can have unexpected effects on the code within the >ENTRY. Now, I would be curious to see what multiple entry points are useful for. [I definitly like multiple exits, but I can very hardly imagine why someone needs multiple entries (well, maybe if someone wants to save a few machine cycles, but then there is always Assembly).] Andras From: wilbaden@netcom.com (W.Baden) Subject: Re: multiple entries Message-ID: References: Date: Sat, 27 Jul 1996 18:21:48 GMT William Clodius (clodius@hotspec.lanl.gov) wrote: : Some flavors of FORTRAN, as I recall, allowed multiple entries : to subroutines, each with its own name. This was an echo of the : underlying assembler that permitted overlapping code sequences. : This is certainly part of FORTRAN 77 and subsequent standards. I : believe it was also part of the FORTRAN 66 standard, which suggests : that it was first implemented in FORTRAN II, because FORTRAN I did not : have subroutines. It does have maintenance problems partly because it : is so rarely used, and partly because changes in earlier parts of the : enclosing procedure can have unexpected effects on the code within the : ENTRY. More than one ENTRY has gone out of fashion, but it was considered essential in the past. What better way is there to implement SIN and COS than as two entries to one routine? In Classical Forth multiple entry was taken as a matter of course. EXPECT and TYPE are two entries to one routine in Classical systems. And who doesn't enjoy the Classical Forth definition of MAX and MIN? : MAX 2DUP < IF BEGIN SWAP DROP ; : MIN 2DUP < UNTIL THEN DROP ; This shows how easy it is to allow multiple entries in Forth. Just relaxÊthe checking of the control-flow stack by `;'. : RED ." Red plays first. " BEGIN Red-plays 0 IF ; : BLUE ." Blue plays first. " THEN Blue-plays AGAIN ; From: "Paul E. Bennett" Subject: Re: many errors in Forth for Windows Date: Sat, 27 Jul 96 13:39:31 GMT Message-ID: <838474771snz@tcontec.demon.co.uk> References: <837820118snz@tcontec.demon.co.uk> <4svptb$t07@newsbf02.news.aol.com> Reply-To: peb@transcontech.co.uk X-NNTP-Posting-Host: tcontec.demon.co.uk X-Mail2News-Path: tcontec.demon.co.uk In article <4svptb$t07@newsbf02.news.aol.com> crepublic@aol.com "CRepublic" writes: > In article <837820118snz@tcontec.demon.co.uk>, "Paul E. Bennett" > writes: > > >Surprisingly enough, there is very little by way of tech support for > Nuclear > >plant from the manufacturers. Any support that is required is up-front in > the > > > >design and checking that the intended system is going to be able to > comply > >with > >the customer and regulatory requirements. > > I sit somewhat corected. Still I cannot but supect if you buy a > $100,000,000 mucler power plant from say france call them up six months > latter and ask a question they are unlikly to hangup on you even if it is > a very stupid question. > It's just that rarely do such projects come from just one source and require a miriad of companies providing their bit. Some of the individual items may indeed have some support from the manufacturer but not the whole power station. After all the guys who run a Nuclear Power Plant are highly trained and very capable technical people. They have to make decisions about the equiment and processes under their control and cannot often wait for the manufacturer to start his business day. Hence they will usually know more than the manufacturers of the equipment about entire systems and their operation. -- Paul E. Bennett Transport Control Technology Ltd. Tel: +44 (0)117-9499861 Going Forth Safely From: logon@my.bbs (CyberTrader) Subject: Earn $10,000+\month Working At Home!! Date: Sat, 27 Jul 96 05:56:00 GMT Message-ID: <4tds47$o58@ns1.autonet.net> Could YOU use an EXTRA $100, $1000, or even $10,000+ every month, whether you work or not?! IT'S FREE! NO COST - NO RISK CALL RIGHT NOW, and start building your income today. $$$ 1-800-223-6477 $$$ ///////// your sponsor's FCI ID # is SH1885969 \\\\\\\ From: spc@gate.net (Sean 'Captain Napalm' Conner) Subject: Re: multiple entries Date: 27 Jul 1996 18:35:16 -0400 Message-ID: <4te5j4$opk@navajo.gate.net> References: NNTP-Posting-User: spc In article wilbaden@netcom.com (W.Baden) writes: >William Clodius (clodius@hotspec.lanl.gov) wrote: > >: Some flavors of FORTRAN, as I recall, allowed multiple entries >: to subroutines, each with its own name. This was an echo of the >: underlying assembler that permitted overlapping code sequences. > >: This is certainly part of FORTRAN 77 and subsequent standards. I >: believe it was also part of the FORTRAN 66 standard, which suggests >: that it was first implemented in FORTRAN II, because FORTRAN I did not >: have subroutines. It does have maintenance problems partly because it >: is so rarely used, and partly because changes in earlier parts of the >: enclosing procedure can have unexpected effects on the code within the >: ENTRY. > > >More than one ENTRY has gone out of fashion, but it was >considered essential in the past. What better way is >there to implement SIN and COS than as two entries to >one routine? > Well, either as two routines written like: double sin(double angle) { ... } double cos(double angle) { return (sin (angle + PIdiv2)); } Or make one a macro, such as: double sin(double angle) { ... } #define cos(a) sin((a)+PIdiv2 [NOTE: is there a way to do macro expansion in Forth? Sure, you can define the following like: : sin ( f -- f ) ... ; : cos ( f -- f ) PI/2 f+ sin ; but's that not quite the same, as cos is calling sin. Would something like: : cos ( f -- f ) POSTPONE PI/2 POSTPONE f+ POSTPONE sin ; immediate be close? Seems kind of clunky to me.] >And who doesn't enjoy the Classical Forth definition of >MAX and MIN? > >: MAX 2DUP < IF BEGIN SWAP DROP ; >: MIN 2DUP < UNTIL THEN DROP ; > >This shows how easy it is to allow multiple entries in >Forth. Just relaxÊthe checking of the control-flow >stack by `;'. > >: RED ." Red plays first. " > BEGIN Red-plays > 0 IF >; >: BLUE ." Blue plays first. " > THEN Blue-plays > AGAIN >; > Just hope that the next fellow to come along to maintain your code can catch on to what you're doing and NOT insert a definition between RED and BLUE. Or what happens if GREEN needs to be added? Before RED? Between? After BLUE? It's maintenance problems that possibly made this style go out of favor. Don't get me wrong, I enjoy doing this stuff in Assembly, but it can get mighty tricky [1]. -spc (And what if an optimizing Forth compiler gets to the 0 IF?) [1] Try, for example, the following 8088 code for example: lamp_on: mov al,TURNON db 03dh lamp_off: mov al,TURNOFF lamp_switch: mov dx,LAMPPORT out dx,al ret From: wilbaden@netcom.com (W.Baden) Subject: Re: Manipulating Return Addresses Message-ID: References: <31F76F75.5E13@headwaters.com> Date: Sun, 28 Jul 1996 02:11:55 GMT Brad Rodriguez (bj@headwaters.com) wrote: > I'm dismayed to see the argument so often offered, "I don't use that > programming technique, so it must not be of any value." The same > argument could be (has been!) offered for vocabularies, DOES>, local > variables, exception handling, memory allocation, and floating > point... to name a few. Yes, I can program without DOES>. But > DOES> makes my programs cleaner, smaller, and faster, so I'd fight > to keep it. Likewise with return stack manipulations. What a remarkable list. These are indeed facilities I don't use much. Not because I don't think they are valuable, but because of Occam's Razor, "It's vain to do with more what can be done with fewer." Before going over them one by one, here is Chuck Moore's triage of Forth systems (Forml 1994). Type 1. Machine language for a hardware Forth engine. Type 2. Toolkit for a software Forth engine. Type 3. Guest of a host. My introduction to Forth was Type 2. Now the Forth I use is Type 3. What's valuable in each type is different. Vocabularies. ============= I used to believe that VOCABULARY was the most important feature of Forth. VOCABULARY was the Forth equivalent of application. Every application I wrote had its own vocabulary. Invoking an application was done by typing its vocabulary name. This is probably still true for Type 2 Forth, or an exclusively Forth environment. For Type 1 Forth or Type 2 dedicated embedded system vocabularies are probably unnecessary. What you can see is what you have. Strangely missing from the Standard is the ability to behead definitions easily. Wordlists can be finagled to do this, but awkwardly. In my Type 3 system I load each application fresh and have a temporarily dedicated system. I still use vocabularies but sparingly. I think the Search-Order wordset is better without the Search-Order Extension wordset. For local definitions WORDLIST can do it the hard way. DOES> ===== I don't think DOES> is as important as WORDLIST. Both foreshadow Object Oriented Programming, but weakly. The main value of DOES> is reducing the number of definitions in an application. Unlike the profane languages, the name for each word defined takes up sometimes precious space in a application. Compare-- : CREATE WIDGET initialize-widget DOES> handle-widget ; WIDGET fred WIDGET barney with-- CREATE 'fred initialize-widget : fred 'fred handle-widget ; CREATE 'barney initialize-widget : barney 'barney handle-widget ; The only real difference is that the first set of definitions is shorter and the second set may be negligibly faster. Local Variables. ================ As I've written before, Forth with local variables is Tiny C with postfix operators. With short definitions that should be typical of Forth, local variables are distracting. An application that "needs" local variables would be written better in another language. As almost all good Forth definitions have no more than three arguments, local variables don't do much. Local variables have too much overhead for too little return. What would be valuable would be local definitions - definitions local to a package of definitions. WORDLIST can done this but awkwardly. As I wrote above, strangely missing from the Standard is the ability to behead definitions easily. Exception Handling. =================== In Standard Forth this means CATCH-THROW. Is CATCH-THROW really that much better than vectoring ABORT ? The examples of actual use of CATCH-THROW that I've seen introduce dynamic spaghetti-code into the application. Memory Allocation. ================== The functions of ALLOCATE-FREE-RESIZE are crucial in the major profane languages, but in Forth we've always had ALLOT. Would those who have implemented ALLOCATE-FREE-RESIZE tell me what applications you have used them for? They seem useful for some specialized applications, but not for general applications, as they are in the major profane languages. Floating Point. =============== Floating Point is not just valuable but necessary for some applications. But not for what I do mostly. And not for what Forth programs do mostly. Double Numbers. =============== (You missed this one.) With the 16-bit arithmetic found in bitty-boxes Double Numbers can be necessary. Since I have 32-bit arithmetic, and would not want to use anything less, my need for Double Numbers is minimal. Return Stack Manipulation. ========================== Applications that need Return Stack Manipulations would be better written in another language. E.g., there are regular expression packages more powerful and more efficient than anything written in Forth that can be had for the downloading. In Type 3 Forth written in C it is trivial to include one in your nucleus. (All these features but local variables are included in ThisForth.) -- Procedamus in pace. Wil Baden Costa Mesa, California From: Chris Jakeman Subject: Re: Manipulating Return Addresses Date: Sat, 27 Jul 1996 14:56:09 +0100 Message-ID: References: <31F80947.3416@forth.com> X-NNTP-Posting-Host: apvpeter.demon.co.uk MIME-Version: 1.0 In article <31F80947.3416@forth.com>, Elizabeth Rather writes >Chris Jakeman wrote: >> Can anyone advise me on the text which should accompany an ANS Forth >> program which is not 100% portable? I've copied the ANS text in >> 4.2.1 and 5.2.2 to give ... >> >> "FOSM is an ANS Forth Program with Environmental Dependencies >> requiring NIP TUCK WITHIN and \ from the Core Extensions word set. >> >> FOSM has the following environmental dependencies: >> [enumerated]... > >IMO, assuming you document all the exceptions along with your claim, you can say >it's a "Standard Program with the following environmental dependencies:..." > Thanks for your advice - the support from this newsgroup is really great. Bye for now _ _______________________| |_____ Chris Jakeman / _Forth_Interest_Group_| |____/ / /_ __ ______ _ _ | | __ at Peterborough / __/ / / / __ / | | | | | |/ / (a cathedral city / / / / / /_/ / | \_| | | < 80 miles north of London) /_/ /_/ /___ / \____| |_|\_\ Where do you come from? / / ______________/ / United Kingdom Voice +44 (0)1733 346477 /_______________/ Chapter From: dvanecek@third-wave.com (David Vanecek) Subject: Re: multiple entries Date: 28 Jul 1996 06:22:04 GMT Message-ID: <4tf0ud$ani@news.third-wave.com> References: <4tco6m$mf9@hkusuc.hku.hk> Reply-To: dvanecek@third-wave.com Zsoter Andras (h9290246@hkuxa.hku.hk) wrote: : Now, I would be curious to see what multiple entry points are useful : for. An old, grey Fortran vet replies: in aircraft simulation code, it was structurally sound to have a single routine to, say, model the engine. One of the multiple entry points could be to initialize the engine to some run point, another for "normal" iteration, yet another, with different argument list altogether, to force it to some arbitrary point, yet another to dump out local variables, (in Fortran, these were all static). In a math environment, you could have one routine maybe to invert a matrix. One of the entry points could be for a matrix of special form, (diagonal, upper triangular?). Or perhaps one entry would be the normal routine entry, say for eigenvalue analysis. Another entry to the same routine could also return additional information, (matrix of eigenvectors). This would be used to (1) save memory, which in Fortran days was very expensive, since the various entries would be expected to share much common code. (2) ease maintenance, since related code would all be in the same "deck." (3) Improve runtime performance, by reducing subroutine calls or swapping. D. Vanecek --- oh--my first post to this group. Greetings, all. From: wilbaden@netcom.com (W.Baden) Subject: Re: multiple entries Message-ID: References: <4te5j4$opk@navajo.gate.net> Date: Sun, 28 Jul 1996 07:46:42 GMT Sean 'Captain Napalm' Conner (spc@gate.net) wrote: Wil Baden wrote: > >More than one ENTRY has gone out of fashion, but it was > >considered essential in the past. What better way is > >there to implement SIN and COS than as two entries to > >one routine? > > > Well, either as two routines written like: > > double sin(double angle) { ... } > double cos(double angle) { return (sin (angle + PIdiv2)); } You're right, of course. But I knew that. > [NOTE: is there a way to do macro expansion in Forth? Sure, you can > define the following like: > > : sin ( f -- f ) ... ; > : cos ( f -- f ) PI/2 f+ sin ; > > but's that not quite the same, as cos is calling sin. Would > something like: > > : cos ( f -- f ) POSTPONE PI/2 > POSTPONE f+ POSTPONE sin ; immediate > > be close? Seems kind of clunky to me.] There is, in ThisForth. : cos PLEASE " PI/2 F+ sin " ; IMMEDIATE And in Standard Forth you can write-- : cos S" PI/2 F+ sin " EVALUATE ; IMMEDIATE > Just hope that the next fellow to come along to > maintain your code can catch on to what you're doing > and NOT insert a definition between RED and BLUE. > Or what happens if GREEN needs to be added? Before > RED? Between? After BLUE? It's maintenance > problems that possibly made this style go out of > favor. You're right again. But I knew that also. > -spc (And what if an optimizing Forth compiler gets to the 0 IF?) It does. "0 IF" becomes an unconditional branch in ThisForth. And nothing is generated for the semicolons because they're preceded by unconditional branches. ThisForth gives a non-fatal warning when it gets such bizarre code. > >And who doesn't enjoy the Classical Forth definition of MAX and MIN? ^^^^^ ^^^^^^^^^ You missed a couple of keywords in what I wrote. The moral of what I have written is: Don't do as I say, do as I do. -- Procedamus in pace. Wil Baden Costa Mesa, California P.S. Thanks for responding. From: Paul Shirley Subject: Re: Is using mult Exits bad pgrming Date: Sun, 28 Jul 1996 11:41:38 +0100 Message-ID: References: <4t8sfd$cg4@nadine.teleport.com> <4t9qre$aoj@hkusuc.hku.hk> <4taiqb$hl2@life.ai.mit.edu> Mime-Version: 1.0 In article <4taiqb$hl2@life.ai.mit.edu>, Mike Coughlin writes > Assembly language programming is much more difficult than >necessary since it uses so many things that the human mind >cannot cope with. A good language like Forth removes sources >of error by removing the methods that cause errors. This puzzles the hell out of me. What are these things asm has 'the human mind cannot cope with', and why do I find asm easier than most HLLs? Good languages reduce errors by filling in the details, doing it correctly every time. At least 50% of my asm errors are forgetting to do something simple (like balance the stack ;) that a HLL would either trap or do for me. The abstractions away from the simple test&branch level of asm provides useful protection from these sort of mistakes. It also allows you to use potentially dangerous techniques with more chance of success. (like exiting from the middle of code) Unfortunately Forth does not provide quite the same level of assistance here (a consequence of extreme flexibility). -- Paul Shirley From: "Paul E. Bennett" Subject: Re: FORTH and TCP/IP Date: Sat, 27 Jul 96 21:43:50 GMT Message-ID: <838503830snz@tcontec.demon.co.uk> References: <4tbp5l$617@news.wco.com> Reply-To: peb@transcontech.co.uk X-NNTP-Posting-Host: tcontec.demon.co.uk X-Mail2News-Path: tcontec.demon.co.uk In article <4tbp5l$617@news.wco.com> root@pacx.com "root" writes: > Gentlemen: I am curious -- Has there been a TCP/IP kernel implemented > in/with/for FORTH? My familiarity with the Language (from years ago) > leads me to believe that FORTH and TCP/IP would be a rather useful > combination. > awaiting comments. All flames forwarded to packet multipliers. Skip couldn't recall when I asked him last a few months back and I do not seem to have seen anything of it yet. We might have to do the research of the requirements and produce some code for it yet. -- Paul E. Bennett Transport Control Technology Ltd. Tel: +44 (0)117-9499861 Going Forth Safely Message-ID: <13@brady.win-uk.net> References: <10@brady.win-uk.net><31F92D44.6228@austin.finnigan.com> Reply-To: stuart@brady.win-uk.net (Stuart Brady) From: stuart@brady.win-uk.net (Stuart Brady) Date: Sun, 28 Jul 1996 17:08:17 GMT Subject: Re: Beginners Help.... In article <31F92D44.6228@austin.finnigan.com>, Tom Zimmer (tzimmer@austin.finnigan.com) writes: >Stuart Brady wrote: >> I have decided to try and learn Forth and I am looking for advice. >> I LIKE Forth. At the moment I have FPC Forth (v3.56) which seems >> FPRIMER.ZIP made in 1992(?) There seem to be some parts missing from the FPRIMER version of FPC. (e.g. ZIMMER.ZIP, SMITH.ZIP, [DIS]ASSEMBLER(?) etc). Also the is mention of an additional 3 lessons by Jack Brown. Are these available somewhere? Talking about the lessons brings me to...WHICH BOOK? I have dabbled in various programming languages and would describe myself as having a reasonably good understanding of computers. I already have a book 'FORTH' by P.A.C. Kail which is a reasonable introduction[but don't metion proofreading]. I have printed out the tutorials with FPC. I am looking for a 'middling to advanced' Forth book. I have seen the recommended texts but I don't know which would fall into this category. All the Best Stuart From: jvn@faraday.clas.Virginia.EDU (Julian V. Noble) Subject: Re: Stack Computer book on-line X-Nntp-Posting-Host: faraday.clas.virginia.edu Message-ID: References: Date: Sun, 28 Jul 1996 17:49:56 GMT jvn@faraday.clas.Virginia.EDU writes: [ remarks re: return of copyright deleted ] > Thanks to Phil Koopman for putting his book on line. However, > as Cliff Stoll notes in "Silicon Snake Oil", on-line documents > are not as useful as hard copy ones. My reference to "Silicon Snake Oil" apparently touched a nerve. I haven't received so many flames since the time I died and went to Hell. (in a handbasket, of course :-) To avoid being classified as a Luddite (look it up if you didn't pay attention in History 101) of the Web, let me amplify the above remark. In the following, "book" refers to ink on paper pages sewn or glued together in sequence. 1. A book is lighter and more portable than the smallest current machine that can access the Web. 2. A book is still readable by candlelight, when the power fails and the battery dies. 3. The print on a cheaply printed book page is far more legible than the output on the highest resolution display that is currently available to mere mortals. It is much easier on the eyes. 4. Unless one is connected to the server by a very high speed line, cross-referencing by flipping a book page is far faster than the electronic analogue. 5. It is easy to annotate a book with a low-tech device known as a pen. The annotation is permanent. 6. When one reads a technical treatise ("Scientific FORTH", e.g.) in book form, while implementing its ideas on a computer, one does not lose one's place in a crash. 7. Sitting with a book in one's lap does not waste expensive bandwidth on the network. 8. A book written 50 years ago may still be read. Many of my programs from the 1970's and 1980's cannot be read since their media --punched tapes, punched cards, magnetic tapes-- are now obsolete. Will CD-ROMs or magnetic disks of current type become as unreadable as 8" floppies now are? If anyone wishes to refute the above points (politely--calling me an old fogey is neither a refutation nor polite, no matter how true it might be), I would be interested to read their views. It seems to me that the individuals who flamed the hottest and most incoherently have not considered the problems associated with on-line books accessed by 28.8Kb modems. I suspect they do not have to pay for access time, but receive it gratis from their institutions. I really have tried to use on-line documentation (on my own machine) in a multitasking system and with two separate computers. Even the latter is not as good as having the book next to the machine. If these observations (which I was glad to see Stoll agreed with) make me a Luddite, so be it. -- Julian V. Noble jvn@virginia.edu From: carl.wall@westonia.com (CARL WALL) Subject: Palmtops and Forth Message-ID: <8C5343A.1CF6000C20.uuout@westonia.com> Date: Fri, 26 Jul 96 18:02:00 -0500 Reply-To: carl.wall@westonia.com (CARL WALL) X-Mailer: PCBoard/UUOUT Version 1.30 Any recomendations on what plamtops have been used with forth and are able to communicate at 38.4K over the serial port. Want to control a machine that uses 38.4k baud. Thanks Carl Carl Wall VE3APY - Toronto, Ontario, Canada Internet: carl.wall@westonia.com --- þ RoseReader 2.52á P003562 Entered at [WESTONIA] From: cwr@cts.com (Will Rose) Subject: Re: Stack Computer book on-line Date: 29 Jul 1996 00:28:18 GMT Message-ID: <4th0j3$fd5@optional.cts.com> References: Julian V. Noble (jvn@faraday.clas.Virginia.EDU) wrote: : jvn@faraday.clas.Virginia.EDU writes: : [ remarks re: return of copyright deleted ] : > Thanks to Phil Koopman for putting his book on line. However, : > as Cliff Stoll notes in "Silicon Snake Oil", on-line documents : > are not as useful as hard copy ones. : My reference to "Silicon Snake Oil" apparently touched a nerve. : I haven't received so many flames since the time I died and went : to Hell. (in a handbasket, of course :-) : To avoid being classified as a Luddite (look it up if you didn't : pay attention in History 101) of the Web, let me amplify the : above remark. In the following, "book" refers to ink on paper : pages sewn or glued together in sequence. : 1. A book is lighter and more portable than the smallest : current machine that can access the Web. Well, no. Given a fairly solid text book, an IBM thinkpad runs it close. I think the new ones weigh around four pounds. : 2. A book is still readable by candlelight, when the power : fails and the battery dies. True, but I last used candles in a powercut in England in the early 50s. : 3. The print on a cheaply printed book page is far more : legible than the output on the highest resolution display : that is currently available to mere mortals. It is much : easier on the eyes. No. My current 15" monitor displays far more readable text than many of the older books I have kicking around. I don't find it a strain on the eyes. : 4. Unless one is connected to the server by a very high speed : line, cross-referencing by flipping a book page is far : faster than the electronic analogue. Perhaps, if you discount search time. But cross-referencing electronically on a *local* book is extremely quick. : 5. It is easy to annotate a book with a low-tech device known : as a pen. The annotation is permanent. Anyone who scribbles on any book is beneath contempt. Under pressure, I'll concede light pencil annotation. : 6. When one reads a technical treatise ("Scientific FORTH", : e.g.) in book form, while implementing its ideas on : a computer, one does not lose one's place in a crash. Well, I don't have computers that crash that much, to be honest. : 7. Sitting with a book in one's lap does not waste expensive : bandwidth on the network. True, but a lot of the time I read electronic books *locally*, and they are very convenient. And there are much bigger wastes of bandwidth around. : 8. A book written 50 years ago may still be read. Many of : my programs from the 1970's and 1980's cannot be read since : their media --punched tapes, punched cards, magnetic tapes-- : are now obsolete. Will CD-ROMs or magnetic disks of current : type become as unreadable as 8" floppies now are? I can still read 8" floppies. I could find someone to read paper tape. But media will always change, for every form of storage. (SSO is a pretty silly book - Stoll's got no clue about the interaction of society and technology, and never had, tho' his earlier book was a fascinating case study). Personally, I prefer hardcopy books for most purposes, but ebooks (eg. cdroms) are *much* more portable and *much* easier to use for reference, so for technical subjects I try and get both. Will cwr@crash.cts.com From: znmeb@teleport.com () Subject: Re: Is using mult Exits bad pgrming Date: 29 Jul 1996 00:42:05 GMT Message-ID: <4th1ct$en0@nadine.teleport.com> References: <4t8sfd$cg4@nadine.teleport.com> Julian V. Noble (jvn@faraday.clas.Virginia.EDU) wrote: : Finally I should note that Glen Haydon says my FSM paper is going to appear : in the electronic version of JFAR, which will appear at a URL that I have : been sworn not to reveal yet. (I know nothing whatsoever about the electronic : version of JFAR, which is a bit surprising since I could have sworn that I : have been a member of its editorial board since 1992 or 1993. But that's : how these things go sometimes...) Try http://www.taygeta.com/jfar/article001.html -- znmeb@teleport.com (M. Edward Borasky) http://www.teleport.com/~znmeb "Outside of a dog, a book is a man's best friend. Inside a dog, it's too dark to read." -- Marx From: znmeb@teleport.com () Subject: Re: Palmtops and Forth Date: 29 Jul 1996 00:38:46 GMT Message-ID: <4th16m$en0@nadine.teleport.com> References: <8C5343A.1CF6000C20.uuout@westonia.com> CARL WALL (carl.wall@westonia.com) wrote: : Any recomendations on what plamtops have been used with forth and : are able to communicate at 38.4K over the serial port. Want to control : a machine that uses 38.4k baud. : Thanks : Carl : Carl Wall VE3APY - Toronto, Ontario, Canada : Internet: carl.wall@westonia.com : --- : þ RoseReader 2.52á P003562 Entered at [WESTONIA] The HP100LX/HP200LX/HP1000CX will all do this. HP100LX (the one I have) is obsolete. The HP200LX includes PDA/organizer capabilites and the HP1000CX is a pure DOS machine suitable for OEM applications. All are 7.91 Mhz 80186 CPUs with 1 - 6 MBytes of RAM. The RAM is partitioned into DOS memory (up to 640K) and RAM disk (the rest). All have an infrared port, a PCMCIA type II slot and a serial port capable of communicating at up to 115200 bits per second. Forths? Any 16-bit DOS Forth will run in these machines. I currently use Wonyong Koh's hForth, but F-PC will run if you have the disk space (3.5 MBytes). Another good one is Frank Sergeant's "Pygmy". For the ultimate in speed, Tom Almy's ForthCMP target compiler compiles Forth directly to machine code. If this is for a ham application, I'd recommend the HP200LX, since the PDA application includes the ability to have the machine wake up and do things, like execute your Forth comm code, at any conceivable scheduled times. If this is for a commercial/OEM project, where cost is important and you're going to write a lot of software, go with the 1000CX because it's cheaper. -- znmeb@teleport.com (M. Edward Borasky) http://www.teleport.com/~znmeb Yesterday, I walked by a BMW. I saw scratches on the bumper, and I stooped down for a closer look. It was engraving: "My Other Car is a '73 Pinto!" From: spc@gate.net (Sean 'Captain Napalm' Conner) Subject: Re: multiple entries Date: 29 Jul 1996 00:37:41 -0400 Message-ID: <4thf6l$1532@seminole.gate.net> References: <4te5j4$opk@navajo.gate.net> NNTP-Posting-User: spc In article wilbaden@netcom.com (W.Baden) writes: >Sean 'Captain Napalm' Conner (spc@gate.net) wrote: > >> [NOTE: is there a way to do macro expansion in Forth? Sure, you can >> define the following like: >> >> : sin ( f -- f ) ... ; >> : cos ( f -- f ) PI/2 f+ sin ; >> >> but's that not quite the same, as cos is calling sin. Would >> something like: >> >> : cos ( f -- f ) POSTPONE PI/2 >> POSTPONE f+ POSTPONE sin ; immediate >> >> be close? Seems kind of clunky to me.] > >There is, in ThisForth. > >: cos PLEASE " PI/2 F+ sin " ; IMMEDIATE > >And in Standard Forth you can write-- > >: cos S" PI/2 F+ sin " EVALUATE ; IMMEDIATE > Ah. Thanks. >> -spc (And what if an optimizing Forth compiler gets to the 0 IF?) > >It does. "0 IF" becomes an unconditional branch in ThisForth. >And nothing is generated for the semicolons because they're >preceded by unconditional branches. > I would think that an optimizing compiler (reguardless of lanague) would take a construct like: 0 if do_this do_that then And not generate any code (since the 0 is immediate and this will always evaluate to false, why include the code?). Or in the case of: 0 if do_this else do_that then generate code as if it appeared as: do_that >ThisForth gives a non-fatal warning when it gets such bizarre code. > At least it gives a warning 8-) >> >And who doesn't enjoy the Classical Forth definition of MAX and MIN? > ^^^^^ ^^^^^^^^^ >You missed a couple of keywords in what I wrote. > I didn't even know it was possible. >The moral of what I have written is: Don't do as I say, do as I do. I'll keep that in mind. -spc (As soon as I get my DWIM compiler ready 8-) From: jwillard44@aol.com (JWillard44) Subject: Re: Palmtops and Forth Date: 29 Jul 1996 00:29:03 -0400 Message-ID: <4themf$dvj@newsbf02.news.aol.com> References: <4th16m$en0@nadine.teleport.com> Reply-To: jwillard44@aol.com (JWillard44) carl.wall@westonia.com (CARL WALL) wrote: > Any recomendations on what plamtops have been used > with forth and are able to communicate at 38.4K over the > serial port. If money is an important consideration, it is possible that the HP-71 will meet your needs. I believe the processor is an 8 bit @ 4Mhz and I know the memory is greatly expandable. As to the communication speed, if this has a chance of meeting your needs, let me know and I will do some research for you. Joel In Ogden From: Brad Eckert Subject: Win32Forth example Date: 29 Jul 1996 04:59:38 GMT Message-ID: <4thgfq$1ogk@news.goodnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.22 (Windows; I; 16bit) (( WINSTACK.F 7/26/96 BNE Here is a simple application for win32forth. You should be able to fload this file and have it start up. The only thing I don't like about it is that you can't fload files while the stack window is active. I tried using source-id to avoid this, but it didn't work in my case (using win32s under windows 3.1). Maybe somebody can find the fix. -- Brad Displays the contents of the data stack after each INTERPRET. )) only forth also definitions wincon also anew stuff decimal 0 value forthsp \ pointers to Forth's stack 0 value forthdepth defer stackinterpret \ extended version of interpret :Object STACK-WINDOW r maxcells 0 do i maxcells forthdepth - - dup 0< if drop s" " else forthdepth maxcells - 0 max - \ push down cells forthsp + @ (.) \ display then temp$ 20 blank temp$ place \ place string margin char-height i * temp$ 1+ 20 TextOut: dc loop r> SelectObject: dc drop \ restore the font s" Stack: [" temp$ place base @ decimal forthdepth (.) temp$ +place s" :" temp$ +place dup (.) temp$ +place base ! s" ]" temp$ +place temp$ count SetTitle: self ;M :M On_Init: ( -- ) On_Init: super char-width char-height z" System" CreateScreenFont: dc to the-font ['] stackinterpret is interpret ;M :M On_Done: ( -- ) ['] _interpret is interpret the-font DeleteObject: dc On_Done: super ;M :M StartSize: ( -- width height ) \ starting window size cellwidth char-width * margin 2* + maxcells char-height * ;M :M MaxSize: StartSize: self ;M :M MinSize: StartSize: self ;M :M StartPos: 400 100 ;M :M WindowTitle: ( -- Zstring ) \ window caption z" Stack" ;M :M WindowStyle: ( -- style ) WS_CAPTION WS_SIZEBOX or WS_SYSMENU or ;M :M ExWindowStyle: ( -- style ) WS_EX_TOPMOST ;M ;Object : wininterpret ( -- ) _interpret depth to forthdepth sp@ to forthsp source-id 0= if paint: stack-window then ; ' wininterpret is stackinterpret start: stack-window From: jwillard44@aol.com (JWillard44) Subject: Re: multiple entries Date: 29 Jul 1996 00:57:32 -0400 Message-ID: <4thgbs$eh8@newsbf02.news.aol.com> References: Reply-To: jwillard44@aol.com (JWillard44) Zsoter Andras (h9290246@hkuxa.hku.hk) wrote: > Now, I would be curious to see what multiple entry > points are useful for. I am sorry I can't give examples from Forth, but consider a routine which initializes a data structure to a specified value. An alternate entry would pick up a zero and fall through to the set routine, thereby becoming a clear routine. A write line routine concludes by emiting a . An alternate entry could provide only the characters. Joel in Ogden Date: 26 Jul 1996 08:57:00 +0100 From: All@business.forth-ev.de (Wolfgang Allinger) Message-ID: <6DbcBKtb7QB@business.forth-ev.de> References: <4r2c5p$o89@hkusuc.hku.hk> <4t1s37$9dk@seagoon.newcastle.edu.au> <4t2c13$t6h@hkusuc.hku.hk> <31F4DE5C.3A34@ix.netcom.com> <31F6EFF8.2BC0@tir.com> Subject: Re: Is using mult Exits bad pgrming On 24 Jul 96 in article <31F6EFF8.2BC0@tir.com> (Michael A. Losh) wrote: >It is my understanding that structured programming, as promoted by >Dijkstra, simply requires that software be broken into _modules_ >that have one entry point and one exit point. Such a module will >guarantee that the thread of execution, as it leaves a module, will >go to one and only one place. ---snipp--- >Forth's words, no matter how many EXITs they have inside, have one >entry point and one exit point*. The EXITs force the code to the >common return point. This is still structured, or nearly so. The >same idea applies to multiple "return();" statements in C. ---snipp--- >So I would say, don't fret over a few extra EXITs or returns, >especially if they prevent a deeply nested mess inside a routine. >Just do not abuse them. The people who get all caught up in a rule >like "one return" do not seem to understand its purpose very well. >That's probably true of most things in life! >-- >Mike Losh mlosh@tir.com Hi Mike, I think, that I understand the purpose of 'one return' very well: I'm not quite shure if Dijkstra also made his statement by thinking on InCircuitEmulation and/or debugging of (machine)code. It is very useful to have only one RETurn statement in a routine. Especially if you have not very much number of possible breakpoints. It's also good practice, If you want to trace programms with a logic analyser. Sometimes I like two RETurns in my (low-level)programs: one for normal exit, the other one for error exit. In forth words I use a lot of 'IF ... EXIT THEN' in the beginning to handle the special cases. A logic analyser is nearly useless in forth, so I do what it makes it easier for me. Bye bye by Wolfgang -- FORTHing @ work Cheap Fast Good ...pick any two of them Dipl.-Ing. Wolfgang Allinger Brander Weg 6 Voice/FAX [+49] [0] 212 / 66 8 11 D-42699 SOLINGEN eMail: all@business.forth-ev.de GERMANY ## CrossPoint v3.1 R ## From: "John Passaniti" Subject: Re: Stack Computer book on-line Date: 29 Jul 1996 05:07:41 GMT Message-ID: <01bb7d0c$b5468d80$c7ace8cd@johnpass> References: > 1. A book is lighter and more portable than the smallest > current machine that can access the Web. Looking in the local technical libraries for the print version of your book, I was unable to do so. One place did say they could probably get it with about a two week turn-around. So while a book that *exists* may be lighter and more portable, my current inability to get your book in physical form renders this statement moot. Or maybe not. I guess a book I don't currently have access to is indeed lighter (in fact, it is zero kilograms). > 2. A book is still readable by candlelight, when the power > fails and the battery dies. Of course, if the power failed and my batteries had died, I probably wouldn't be working with my computer in the first place, and I probably wouldn't want to read your book. If it makes you feel any better, I could go kill a few trees and use up some paper at work by printing out your text. Then I could indeed read it by candlelight. Does reading your book by candlelight make some of the passages more romantic or mysterious? I always found reading by candlelight to be awfully hard on the eyes, which leads us to your next point... > 3. The print on a cheaply printed book page is far more > legible than the output on the highest resolution display > that is currently available to mere mortals. It is much > easier on the eyes. But you don't get that kewl rippling effect when you eat potato chips in front of your CRT. Actually, with my vision, I prefer reading books online because I can do something you can't do with a book-- you can change the font size or even change the font type to something more readable. I guess you could do this with a book. OCR the book. Render it with your favorite font at whatever size is best for your vision. Print it out. Gosh, I guess you got me there! Books really are better! Geez. I should mention my blind friend. He reads with a voice synthesizer. Go ahead and guess how valuable the printed version of your book is to him! > 4. Unless one is connected to the server by a very high speed > line, cross-referencing by flipping a book page is far > faster than the electronic analogue. Solved that problem too. I am bound by a 28.8k modem, so I downloaded all of your HTML pages to my local hard drive with just a few clicks of my magic mouse. I then indexed them with some home-brew software. Now I can instantly jump to any occurrence of a word or phrase as fast as I can type. > 5. It is easy to annotate a book with a low-tech device known > as a pen. The annotation is permanent. Since I have your book downloaded to my hard drive, I can annotate your book with a device known as a text editor-- the same device (I assume) you wrote the book with in the first place. Or did you dunk your quill into an inkwell and carefully pen each letter? Here's something else to consider. If I did have a printed version of your book, I certainly could decorate the pages with all sorts of notes. But those are *my* notes. What about *your* updates and corrections to the book? With your online version, you can issue a change instantly. I did see a horror movie once where this dead guy who wrote a book was able to change the text of printed copies of the book FROM BEYOND THE GRAVE! Unless you have tapped into that same supernatural power, having your book online is just a tad better. You don't have to sign any pacts with Satan, and you don't have to cover yourself with ectoplasm. > 6. When one reads a technical treatise ("Scientific FORTH", > e.g.) in book form, while implementing its ideas on > a computer, one does not lose one's place in a crash. Got me there. Of course, my code never crashes... much. Here's another stunning revelation. If the computer crashes, I'm probably going to be more interested in rebooting it than reading your book. True, my mind does start to wander while the pretty Microsoft logo flashes up on the screen for all of 30 seconds. I usually use this as a time to pause and reflect on the day, rifle off a couple quick daily affirmations, and scratch my butt. So I guess I simply wouldn't have the time to read your book after the crash. Maybe this affects people on UNIX boxes more, because they typically take a couple minutes to boot. When I'm in front of my UNIX box, system crashes usually trigger me to get up and get a snack. Maybe this is another benefit of your printed book-- if I did have it there, I probably wouldn't eat that candy bar I know I shouldn't. > 7. Sitting with a book in one's lap does not waste expensive > bandwidth on the network. But it does prevent your love-slave from sitting in your lap and disrupting your thoughts of computer science with raw lusty sex. Hubba hubba. Actually, again, I downloaded your book to my hard drive. I have *zero* network bandwidth being used when I read your book. The initial download happened when I was asleep, so I really didn't care how long it took. Actually, it ended up taking far less time to download your book than most of the porn in the alt.* newsgroups. > 8. A book written 50 years ago may still be read. Many of > my programs from the 1970's and 1980's cannot be read since > their media --punched tapes, punched cards, magnetic tapes-- > are now obsolete. Will CD-ROMs or magnetic disks of current > type become as unreadable as 8" floppies now are? Actually, I can still read 8" floppies and paper tape. I really should clean the basement. Will the magnetic disk your book now resides on be readable in the future? I guess that depends on if I decide your book has value and I want to take it with me when I move from magnetic disks to bioholocubes that use an alien technology found in the year 2015. I'll simply click with my virtual reality helmet on your book and drag it to my bioholocube. A pleasant sound will then announce your book has been moved to the next technology. Wheee! Of course, I might find your book boring useless trash. In which case I won't copy it to my bioholocube. But gosh, if I found the digital version of your book boring useless trash, what great loss is there if I can't copy it? Consider the alternative. I'm cleaning out the basement (finally) and come across your printed book of boring useless trash. I make a decision to toss it in the garbage. Guess what-- in either physical or digital form, that book is no longer accessible! Although it probably will contribute to a landfill project somewhere. To be clear, I find your book very valuable, not boring useless trash. That's just a dramatic device. For effect, or something. > I really have tried to use on-line documentation (on my own machine) > in a multitasking system and with two separate computers. Even the > latter is not as good as having the book next to the machine. If > these observations (which I was glad to see Stoll agreed with) make > me a Luddite, so be it. Stoll makes some great points about actually taking the time to *think* about how technology may affect us. It's often subtle and can sometimes be slightly sinister. (I love alliteration.) And he is certainly fun to watch his overly animated speeches. But Stoll (like you) seems stuck in his own idiom. You can spend so much time analyzing the effects of technology that you never go forward. Recognize that while you find online text to be less useful than printed text, some of us have other ways of working that makes it *more* useful. I am very glad you made your book available electronically. I will probably purchase the printed version when I get a chance or the local bookstores can find it. ----------------------------------------------------------------------- John Passaniti He says to me, "You've got style, baby. But if jpass@frontiernet.net you're going to be a REAL villain, you've got to get a gimmick." And so I go, I say, "a gimmick, yeah, that's it! HIGH EXPLOSIVES! AH-HAHAHA!" Date: 26 Jul 1996 08:36:00 +0100 From: All@business.forth-ev.de (Wolfgang Allinger) Message-ID: <6DbcAzYb7QB@business.forth-ev.de> References: <4t5plk$fca@hkusuc.hku.hk> Subject: Re: Is using mult Exits bad pgrming On 24 Jul 96 in article <4t5plk$fca@hkusuc.hku.hk> (Zsoter Andras) wrote: --- snipp --- >BTW: Another use of multimple exits is my favorite construct (good >for factoring into very small, and readable words) is: > > Blah, blah IF EXIT ENDIF > The rest of the word > >Instead of the IF ELSE or between IF and EENDIF. > >I don't know why, but I like it, even though I use it more often >when programming in Pascal or C than in Forth. > >Andras Hallo Andras, I like that too! I do it since many years now and I'm still happy. I think Leo Brodie mentioned this style in one of his excellent books. Wolfgang -- FORTHing @ work Cheap Fast Good ...pick any two of them Dipl.-Ing. Wolfgang Allinger Brander Weg 6 Voice/FAX [+49] [0] 212 / 66 8 11 D-42699 SOLINGEN eMail: all@business.forth-ev.de GERMANY ## CrossPoint v3.1 R ## From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: Stack Computer book on-line Date: 29 Jul 1996 06:26:32 GMT Message-ID: <4thlio$fvl@hkusuc.hku.hk> References: Julian V. Noble (jvn@faraday.clas.Virginia.EDU) wrote: > 1. A book is lighter and more portable than the smallest > current machine that can access the Web. Unless! Unless, you can store books locally on your HD/CD-ROM and you live in a place like Hong Kong where most of the people do *NOT* have several square miles to store books in. I think if you compare the amount of information which can be stored "inside" a laptop and in a texbook of the same physical dimensions and/or weight you will be able to see that you are actually saving space by using the electronic form. Andras From: spc@gate.net (Sean 'Captain Napalm' Conner) Subject: Re: Manipulating Return Addresses Date: 29 Jul 1996 03:02:54 -0400 Message-ID: <4thnmu$250e@seminole.gate.net> References: <4t2jq6$csr@majipoor.cygnus.com> <4t2uo2$f16@hkusuc.hku.hk> <4t5crm$94d@majipoor.cygnus.com> NNTP-Posting-User: spc In article <4t5crm$94d@majipoor.cygnus.com> aph@phal.cygnus.co.uk (Andrew Haley) writes: >Zsoter Andras (h9290246@hkuxa.hku.hk) wrote: > >: Well, in DOOF I use the machine stack as return stack (as all >: subroutines are created equal), but you have >: *NO* way to know what is underneath the top of the stack. >: To make things even worse in the SPARC version even that is not clear >: where the return address is, and how much it is deep inside the >: stack (as different operations put certain things onto the stack >: between subroutine calls which are different sized from the items >: put to this stack by >R). > >But why does anyone use subroutine calls _at all_ in a Forth >implemented in C? If the interpreter and the primitives are all >within the scope of a single function, register variables can be used >for the interpreter's pointers (U, R, S, and I) and the interpreter >itself can be a big switch statement. > It can certainly be done that way (and I've seen an implimentation done that way). One the plus side, yes, certain variables can be in registers thus possibly speeding up execution time. On the two side, you 1) have this huge multi-page routine 2) may be difficult to maintain Since now (for all appearences) local variables now take on the scope of global variables (each case in essence becomes a routine) and it may be difficult to add primitives. Doing it the other way (each primitive is a subroutine) you gain modularity, but at the expense of (potentially) more execution time and more memory usage. But each primitive is isolated and probably more maintainable. It's a trade off (and I myself would go for the latter approach). >: So the ONLY reliable way to use this stack is to stick with >R R R> , >: and balance them inside a definition! > >: BTW: Why is it necessary to manipulate the return addresses on the >: return stack? > >It's not, but: > >a. If the R-stack is not used for nexting, *every task* now has to >have three stacks (machine stack, parameter stack, return stack) >rather than two, and > >b. Doing a C function call, with all of the usual messing around with >frame pointers, etc, is not going to be quicker than pushing a single >value onto the R stack. (Or is it? Maybe in some architectures it's >genuinely quicker to call a function than to do { *--sp = ip; }. Does >anyone know of such an architecture?) > It depends upon the compiler and the architecture. For instance, the MIPS C compiler (at one of the higher optimization levels) can take the following function (taken from my own Forth-like Language, somewhat modified for this example): void int_add(void) { int s1; int s2; int d; s1 = StackPop(INT); s2 = StackPop(INT); d = s1+s2; StackPush(d,INT); } and (assuming that StackPush() and StackPop() are macros) make the following observations: three local variables, the address of which are never taken, so they can live in registers (the MIPS, being RISC, has plenty) doesn't call any other functions, so a stack frame is uneeded So, in this case, the overhead of doing a function call is minimized (and in the case of the MIPS CPU and compiler, it can determine which global values can live in registers (up to 8) and the overhead of a function call that doesn't make a stack frame is a single cycle). From: sca@refugee.engr.sgi.com (Steve Alexander) Subject: Re: Stack Computer book on-line Date: 29 Jul 1996 08:20:18 GMT Message-ID: <4ths82$6mt@murrow.corp.sgi.com> References: <01bb7d0c$b5468d80$c7ace8cd@johnpass> In article <01bb7d0c$b5468d80$c7ace8cd@johnpass>, John Passaniti wrote: >> 8. A book written 50 years ago may still be read. Many of >> my programs from the 1970's and 1980's cannot be read since >> their media --punched tapes, punched cards, magnetic tapes-- >> are now obsolete. Will CD-ROMs or magnetic disks of current >> type become as unreadable as 8" floppies now are? > >Actually, I can still read 8" floppies and paper tape. I really should >clean the basement. Will the magnetic disk your book now resides on be >readable in the future? I guess that depends on if I decide your book has >value and I want to take it with me when I move from magnetic disks to >bioholocubes that use an alien technology found in the year 2015. I'll >simply click with my virtual reality helmet on your book and drag it to my >bioholocube. A pleasant sound will then announce your book has been moved >to the next technology. Wheee! Before I get flamed, let me just mention that I like both online documentation and printed documentation. How's that for fence-sitting? Having written that, I think the point Stoll was trying to make had more to do with the process of historical research. A large percentage of the time, historians gather information from things that are not considered "valuable," such as draft documents, personal journals, letters, handwritten notes, etc. A lot of that content may be lost since people won't feel it is worth preserving, and media formats change much faster now, unlike paper; its basic design has not changed for a while. I picture a building full of History graduate students trying to maintain obsolete computers so that old media can be read and converted. "What the heck is a DECtape, Jim?" Also, I believe that I read a few years back that a lot of the raw data collected in the 50s and 60s is now useless since the tape formats (probably 80-column card images) can't be interpreted without the original computer programs. Don't quote me on this, I can't remember the source... -- Steve Alexander | Silicon Graphics, Inc. | +1 (415) 933-6172 (Voice) sca@sgi.com | http://reality.sgi.com/sca | +1 (415) 933-0513 (FAX) From: chong@csd.hku.hk (Dr. C.F. Chong) Subject: Re: Stack Computer book on-line Date: 29 Jul 1996 10:50:21 GMT Message-ID: <4ti51d$mh7@ns.cs.hku.hk> References: <01bb7d0c$b5468d80$c7ace8cd@johnpass> <4ths82$6mt@murrow.corp.sgi.com> Steve Alexander (sca@refugee.engr.sgi.com) wrote: : In article <01bb7d0c$b5468d80$c7ace8cd@johnpass>, : John Passaniti wrote: : >> 8. A book written 50 years ago may still be read. Many of : >> my programs from the 1970's and 1980's cannot be read since : >> their media --punched tapes, punched cards, magnetic tapes-- : >> are now obsolete. Will CD-ROMs or magnetic disks of current : >> type become as unreadable as 8" floppies now are? : > : >Actually, I can still read 8" floppies and paper tape. I really should : >clean the basement. Will the magnetic disk your book now resides on be : >readable in the future? I guess that depends on if I decide your book has : >value and I want to take it with me when I move from magnetic disks to : >bioholocubes that use an alien technology found in the year 2015. I'll : >simply click with my virtual reality helmet on your book and drag it to my : >bioholocube. A pleasant sound will then announce your book has been moved : >to the next technology. Wheee! : Before I get flamed, let me just mention that I like both online documentation : and printed documentation. How's that for fence-sitting? : Having written that, I think the point Stoll was trying to make had more to do : with the process of historical research. A large percentage of the time, : historians gather information from things that are not considered "valuable," : such as draft documents, personal journals, letters, handwritten notes, etc. : A lot of that content may be lost since people won't feel it is worth : preserving, and media formats change much faster now, unlike paper; its basic : design has not changed for a while. : I picture a building full of History graduate students trying to maintain : obsolete computers so that old media can be read and converted. "What the heck : is a DECtape, Jim?" : Also, I believe that I read a few years back that a lot of the raw data : collected in the 50s and 60s is now useless since the tape formats (probably : 80-column card images) can't be interpreted without the original computer : programs. Don't quote me on this, I can't remember the source... An Economist article some time ago mentioned that some sizable collection of tapes (about Nixon?) can only be read by one machine. (May be someone can recall the story better, I cannot check because I only keep issues up to about 3 months for lack of space.) - c f chong. : -- : Steve Alexander | Silicon Graphics, Inc. | +1 (415) 933-6172 (Voice) : sca@sgi.com | http://reality.sgi.com/sca | +1 (415) 933-0513 (FAX) From: h9290246@hkuxa.hku.hk (Zsoter Andras) Subject: Re: multiple entries Date: 29 Jul 1996 11:32:51 GMT Message-ID: <4ti7h3$sem@hkusuc.hku.hk> References: <4thgbs$eh8@newsbf02.news.aol.com> JWillard44 (jwillard44@aol.com) wrote: >Zsoter Andras (h9290246@hkuxa.hku.hk) wrote: >> Now, I would be curious to see what multiple entry >> points are useful for. > I am sorry I can't give examples from Forth, but consider a routine >which initializes a data structure to a specified value. An alternate >entry would pick up a zero and fall through to the set routine, thereby >becoming a clear routine. > A write line routine concludes by emiting a . An alternate >entry could provide only the characters. But these all look like bad factoring. Why not factor out the common part of the two "entries" into a third routine, and make two routines (which make use of the third one) which provide the functionality of the two entry points of the original monolite beast? Well, you might loose a couple of CPU cycles for the additional call, but how often does it matter? Andras From: Bernd Paysan Subject: Re: Stack Computer book on-line Date: Mon, 29 Jul 1996 15:47:35 +0200 Message-ID: <31FCC0F7.488B@informatik.tu-muenchen.de> References: <01bb7d0c$b5468d80$c7ace8cd@johnpass> <4ths82$6mt@murrow.corp.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (X11; I; HP-UX A.09.05 9000/720) Steve Alexander wrote: > Before I get flamed, let me just mention that I like both online documentation > and printed documentation. How's that for fence-sitting? I don't like tons of manuals with two-level index just to read the one page I need (online manuals are a gift, not a burden). Today, I would not read novells on computer screens. > I picture a building full of History graduate students trying to maintain > obsolete computers so that old media can be read and converted. "What the heck > is a DECtape, Jim?" ROTFL :-). > Also, I believe that I read a few years back that a lot of the raw data > collected in the 50s and 60s is now useless since the tape formats (probably > 80-column card images) can't be interpreted without the original computer > programs. Don't quote me on this, I can't remember the source... It's more likely that the information on the tape is completely gone. I can't imagine any higher level of cryptography applied to these tapes (Read Solomon would be difficult enough), so even if the character set, the bit size and the format is unknown, it can be easily retrieved using some cryptanalytic methods. -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: rivie@intergate.daautah.com (Caldera Desktop User) Subject: Re: Palmtops and Forth Date: 29 Jul 1996 15:22:43 GMT Message-ID: References: <4th16m$en0@nadine.teleport.com> <4themf$dvj@newsbf02.news.aol.com> Reply-To: ivie@cc.usu.edu In article <4themf$dvj@newsbf02.news.aol.com>, JWillard44 wrote: >carl.wall@westonia.com (CARL WALL) wrote: >> Any recomendations on what plamtops have been used >> with forth and are able to communicate at 38.4K over the >> serial port. > > If money is an important consideration, it is possible that the HP-71 >will meet your needs. I believe the processor is an 8 bit @ 4Mhz and I AFAIK, HP hasn't built any HP-71s in a long time. Roger Ivie ivie@cc.usu.edu From: gratz@ite.inf.tu-dresden.de (Achim Gratz) Subject: Re: multiple entries Date: 29 Jul 1996 19:24:38 +0200 Message-ID: <4tis4m$8er@ite127.inf.tu-dresden.de> References: <4tco6m$mf9@hkusuc.hku.hk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-reply-to: h9290246@hkuxa.hku.hk's message of 27 Jul 1996 09:40:38 GMT >>>>> "Zsoter" == Zsoter Andras writes: Zsoter> Now, I would be curious to see what multiple entry points Zsoter> are useful for. [I definitly like multiple exits, but I Zsoter> can very hardly imagine why someone needs multiple entries Zsoter> (well, maybe if someone wants to save a few machine Zsoter> cycles, but then there is always Assembly).] The only thing I've used it for is to skip some tests when you know for sure they aren't needed or some special cases allow for better optimisation. If used as described, it's really much more readable than a bunch of computed GOTOs and it does save the test. With the current optimizer technology this is not much of an advantage anymore. You might be able to use it in places where you'd need a switch with fallthrough and to have some crude form of "overloaded function" (sorry for the C++-ism). You do even wierder stuff, but then you might not be able to figure out what you wrote two weeks ago. This is not limited to FORTRAN, though ;-) -- Achim Gratz. --+<[ It's the small pleasures that make life so miserable. ]>+-- WWW: http://www.inf.tu-dresden.de/~ag7/{english/} E-Mail: gratz@ite.inf.tu-dresden.de Phone: +49 351 4575 - 325 From: strohm@mkol2.dseg.ti.com (john r strohm) Subject: Re: WebBook Patent protection Date: 29 Jul 1996 16:03:23 GMT Message-ID: <4tincb$8if@mksrv1.dseg.ti.com> References: <4s479e$1081@IRIS> <4s5e3o$m6h@newsbf02.news.aol.com> TheWebBook (thewebbook@aol.com) wrote: : In article <4s479e$1081@IRIS>, William H. Stewart : writes: : >I wonder if your taugh a class in Forth in Dallas around 1983 -- If you : did I : >was one of those who had the : >chance to understand what it was all about. For this I truly thank you! : Bill, : Blush. Yes, that was me. I rejoined EDS in 1985 and moved to the Detroit : area and didn't have much of a chance to think about Forth until last : year. I remember a presentation to the Dallas FIG chapter, I think it was yours, in which a pointer named "ROVER" was walking over a data structure of some sort. At one point, there was a line in the code where ROVER was moved off of the current object. When the lecturer was asked about it, the comment was "Yes, ROVER has teeth!" The whole room died laughing at that point. Was that you? --John From: znmeb@teleport.com () Subject: Re: Stack Computer book on-line Date: 29 Jul 1996 19:39:49 GMT Message-ID: <4tj425$h4k@nadine.teleport.com> References: <01bb7d0c$b5468d80$c7ace8cd@johnpass> <4ths82$6mt@murrow.corp.sgi.com> <31FCC0F7.488B@informatik.tu-muenchen.de> Content-Type: text Content-Length: 1487 Quoth the Bernd Paysan (paysan@informatik.tu-muenchen.de): >Steve Alexander wrote: >> I picture a building full of History graduate students trying to maintain >> obsolete computers so that old media can be read and converted. "What the heck >> is a DECtape, Jim?" >> Also, I believe that I read a few years back that a lot of the raw data >> collected in the 50s and 60s is now useless since the tape formats (probably >> 80-column card images) can't be interpreted without the original computer >> programs. Don't quote me on this, I can't remember the source... >It's more likely that the information on the tape is completely gone. I can't >imagine any higher level of cryptography applied to these tapes (Read Solomon >would be difficult enough), so even if the character set, the bit size and the >format is unknown, it can be easily retrieved using some cryptanalytic methods. >-- >Bernd Paysan >"Late answers are wrong answers!" >http://www.informatik.tu-muenchen.de/~paysan/ The story as I heard it was that someone wanted to do a statistical project using US Census data. Naturally, they went backwards in time. When they got to the 1960 census, they discovered that the data files were indeed archived, but they were on seven-track magnetic tape. No problem, just run them through a converter. Well, it turns out that there were no working seven-track tape drives available! I think they finally located one in Mexico or Eastern Europe or an IBM museum somewhere. -- znmeb@teleport.com (M. Edward Borasky) http://www.teleport.com/~znmeb How to Stop A Folksinger Cold # 2 "Are you going to Scarborough Fair?..." No. From: znmeb@teleport.com () Subject: Re: Is using mult Exits bad pgrming Date: 29 Jul 1996 19:48:42 GMT Message-ID: <4tj4iq$h4k@nadine.teleport.com> References: <4r2c5p$o89@hkusuc.hku.hk> <6DbcBKtb7QB@business.forth-ev.de> Wolfgang Allinger (All@business.forth-ev.de) wrote: : I think, that I understand the purpose of 'one return' very well: : I'm not quite shure if Dijkstra also made his statement by thinking on : InCircuitEmulation and/or debugging of (machine)code. Dijkstra has been in the business since before there were ones and zeroes :-). His principles are applicable to *all* kinds of programming: scientific and commercial applications, embedded, assembler, compilers, operating systems -- even Forth, as some code I'm in the process of writing up for Forth Dimensions shows. : It is very useful to have only one RETurn statement in a routine. : Especially if you have not very much number of possible breakpoints. It's : also good practice, If you want to trace programms with a logic analyser. : Sometimes I like two RETurns in my (low-level)programs: one for normal : exit, the other one for error exit. : In forth words I use a lot of 'IF ... EXIT THEN' in the beginning to : handle the special cases. A logic analyser is nearly useless in forth, so : I do what it makes it easier for me. Correct me if I'm wrong, but doesn't a logic analyzer operate by sampling the busses and displaying instruction and data addresses? If so, I'd think it would be possible to write your Forth code in a manner that catered to this. : -- : FORTHing @ work Cheap : Fast Good ...pick any two of them I'll take *real* cheap and *real* fast! -- znmeb@teleport.com (M. Edward Borasky) http://www.teleport.com/~znmeb I support the right to keep and arm bears. From: Jan Klier Subject: Re: Stack Computer book on-line Date: Mon, 29 Jul 1996 13:53:44 -0600 Message-ID: <31FD16C8.588B@gr.hp.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.02 (X11; I; HP-UX A.09.05 9000/712) Julian V. Noble wrote: > 1. A book is lighter and more portable than the smallest > current machine that can access the Web. > > 2. A book is still readable by candlelight, when the power > fails and the battery dies. > > 3. The print on a cheaply printed book page is far more > legible than the output on the highest resolution display > that is currently available to mere mortals. It is much > easier on the eyes. > > 4. Unless one is connected to the server by a very high speed > line, cross-referencing by flipping a book page is far > faster than the electronic analogue. > > 5. It is easy to annotate a book with a low-tech device known > as a pen. The annotation is permanent. > > 6. When one reads a technical treatise ("Scientific FORTH", > e.g.) in book form, while implementing its ideas on > a computer, one does not lose one's place in a crash. > > 7. Sitting with a book in one's lap does not waste expensive > bandwidth on the network. > > 8. A book written 50 years ago may still be read. Many of > my programs from the 1970's and 1980's cannot be read since > their media --punched tapes, punched cards, magnetic tapes-- > are now obsolete. Will CD-ROMs or magnetic disks of current > type become as unreadable as 8" floppies now are? > I think a lot of your points are very well on target. But I had a few comments anyway: 1. While reading online documentation is still a pain (bad software, few standards, slow transmission), nothing has come to this world and was perfect from the beginning. Many things come to a very selected audience first, which happened to have the resources to use it, and then it broadens as equipment catches up and becomes more available and more affordable. Take for example the Internet - for many years it was a very closed audience that had access to it, just because of the cost of getting hooked up to it. Today, everybody gets on it for $10/month with just a modem. I guess, what I'm getting to is, that it's good that this opportunity is being explored, that first products come out and start shaking out the weeds. And even though it's not for everybody today, because of lack of bandwidth or display capabilities, it could very well establish the need for these things and make them happen. OTOH, if the need isn't created, nobody is going to invest in providing these things (not saying that online documentation is the only driving factor for more bandwidth). 2. I think it's certainly good for the environment if we move to electronic publishing. Last decades effort at the paperless office has more than backfired and we're now consuming more paper than ever, even though we have the theoretical abilities to do it electronically (if we would catch up with our software). Especially, since most modern computer books aren't read first to last page, a lot of paper is wasted. I typically read only 10% of most of my computer books that I buy, simply because I'm interested in only certain topics, but can only find them covered in books that also contain many uninteresting stuff. Or for that matter, take dictionaries or encyclopidias: What percentage of the encyclopidia britanica are you ever gonna read in your life, and yet many people keep a copy of it at home. Some volumes might never be opened. Now, in the old days that was the only way you could have these data readily available. Today we have alternatives that are more cost-effective and better for the environment. The whole concept of information on demand hasn't been explored enough - what about buying only chapter 3, 5 and 8 of a book that you're interested in, instead of paying for the whole book? 3. A book isn't necessarily lighter. Have you ever looked at the programmers or users manual of many popular operating systems (Sun) or compilers (Borland). The go into the tenths of pounds, some of them you cannot carry in a single pass. Yet, both of them fit onto a single CD, which almost weights nothing. And you cannot count the whole weight of the computer, since you share the computer for reading any number of such books. 4. There's also the issue of space. Printed materials take much more space than electronically published materials. Years ago, a corporate phone bill could require a fork lift for moving it around, not to speek of the trouble of reading it. Today, AT&T sends you a properly indexed CD with all the data. Lightweight and easy to use and much easier to store. Just my $0.02 Jan -- The opinions expressed above are my own and have nothing to do with my employer ******************************************************************************* Jan Klier Software Design Engineer jank@gr.hp.com Hewlett Packard - Storage System Division, Greeley CO From: jmrubin@ix.netcom.com (Joel Rubin) Subject: Re: FORTH and TCP/IP Date: 29 Jul 1996 20:40:16 GMT Message-ID: <4tj7jg$r2m@dfw-ixnews3.ix.netcom.com> References: <4tbp5l$617@news.wco.com> <838503830snz@tcontec.demon.co.uk> X-NETCOM-Date: Mon Jul 29 3:40:16 PM CDT 1996 In article <838503830snz@tcontec.demon.co.uk>, peb@transcontech.co.uk says... > >In article <4tbp5l$617@news.wco.com> root@pacx.com "root" writes: > >> Gentlemen: I am curious -- Has there been a TCP/IP kernel implemented >> in/with/for FORTH? My familiarity with the Language (from years ago) >> leads me to believe that FORTH and TCP/IP would be a rather useful >> combination. >> awaiting comments. All flames forwarded to packet multipliers. > >Skip couldn't recall when I asked him last a few months back and I do not seem >to have seen anything of it yet. We might have to do the research of the >requirements and produce some code for it yet. > Going the other way, I wonder if anyone has considered a Telnet client (for Winsock or Unix Berkeley socket services) which has Forth as a scripting language. Since most socket clients involve telneting to a certain port of a server and then giving pidgin English commands and getting data, such a Telnet program could easily generate a news client, an email client, an ftp client, et alia. (For example, if I want to get my email, and I want to do it the hard way, I can Telnet to port 110 of popd.ix.netcom.com, and give the commands "user jmrubin", "pass ", "retr 1", "dele 1", "quit".) -- "The Misinformation Highway Begins Here." -- Monty Python Web Site (http://www.pythonline.com) From: "Michael A. Losh" Subject: Re: multiple entries Date: Mon, 29 Jul 1996 17:48:22 -0400 Message-ID: <31FD31A6.328A@tir.com> References: <4tco6m$mf9@hkusuc.hku.hk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (Win95; I) Zsoter Andras wrote: > Now, I would be curious to see what multiple entry points are useful > for. In the last few years, Chuck Moore published the code for his OK programming environment. There are places where he uses multiple entry points. I think one of them is in a formatting routine for numeric output (entry based on number of digits to display for byte, word, and doubleword numbers), and another was in memory moves for a BitBlit type of function. The multiple entry points allow repetitive processing to be done quickly for different numbers of repetitions, and minimize return stack usage, which is important for the MuP21 chip he designed. But this type of code is not for the faint-hearted! :) -- Mike Losh mlosh@tir.com From: Stephen Pelc Subject: Re: FORTH and TCP/IP Date: Mon, 29 Jul 96 23:18:55 GMT Message-ID: <838682335snz@mpeltd.demon.co.uk> References: <4tbp5l$617@news.wco.com> <838503830snz@tcontec.demon.co.uk> Reply-To: sfp@mpeltd.demon.co.uk X-NNTP-Posting-Host: mpeltd.demon.co.uk X-Mail2News-Path: mpeltd.demon.co.uk In article <838503830snz@tcontec.demon.co.uk> peb@transcontech.co.uk "Paul E. Bennett" writes: > In article <4tbp5l$617@news.wco.com> root@pacx.com "root" writes: > > Gentlemen: I am curious -- Has there been a TCP/IP kernel implemented > > in/with/for FORTH? My familiarity with the Language (from years ago) > > leads me to believe that FORTH and TCP/IP would be a rather useful > > combination. > > awaiting comments. All flames forwarded to packet multipliers. > > Skip couldn't recall when I asked him last a few months back and I do not seem > to have seen anything of it yet. We might have to do the research of the > requirements and produce some code for it yet. As far as I know there are *at least* commercial implementations available now or real soon now (working prototypes). Greg Bailey - Athena - available now AN Other - not sure of leagal status MPE/DelaComms - Industrial networking stack for Ethernet/SLIP/Fieldbus Of course I know most about the last one. They are all targeted to different application arenas. For more details contact MPE at one of the contact addresses below. -- Stephen Pelc, sfp@mpeltd.demon.co.uk MicroProcessor Engineering - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 1703 631441, fax: +44 1703 339691 From: jimmie@ccs.uky.edu (Jimmie Mayfield) Subject: Re: Stack Computer book on-line Date: 30 Jul 1996 03:15:35 GMT Message-ID: <4tjuoo$i3g@service3.uky.edu> References: <31f61e27.6475492@usenet.interramp.com> <4thlio$fvl@hkusuc.hku.hk> Originator: jimmie@ In article <4thlio$fvl@hkusuc.hku.hk>, h9290246@hkuxa.hku.hk (Zsoter Andras) writes: > >Julian V. Noble (jvn@faraday.clas.Virginia.EDU) wrote: > >> 1. A book is lighter and more portable than the smallest >> current machine that can access the Web. > >Unless! Unless, you can store books locally on your HD/CD-ROM and you >live in a place like Hong Kong where most of the people do *NOT* have >several square miles to store books in. > I use both printed and electronic media (ranging from simply running ghostview on the postscript version of a book to more elaborate hypertextish utilities like gnu info to HTML formats). I think they each have their uses. Electronic media is certainly more convenient if you have it available but do not have the hardcopy version available. As a programmer, however, I tend to prefer hardcopy material if I'm reading about something in-depth. (If it's just a quick reference, then electronic media wins hands down) For me, there are several reasons: 1. Someone brought up the point about screen resolution being a limiting factor. This is a biggie for me when I'm using ghostview to read my compiler docs. In order for me to see an entire page, either my window needs to take up the whole display or I have to use a font that's barely readable or both. I am unable to have both ghostview and my editor windows visible at the same time. So, printed documentation is better for me in this respect (I can switch from a book to my screen in a fraction of a second...on a slow XStation, it might take several seconds to resize/move a window. That adds up over a day). Often I'll use two monitors - one for coding, the other for documentation - if I'm forced to use electronic documentation extensively. 2. I think online documentation is still evolving...some formats are more usable than others...some HTML-format docs are particularly nice (some of the Linux programming guides come to mind). IBM's Bookmanager/Read program is also particularly usable. Still, I occasionally want to print a certain page so I can write comments. Some electronic forms don't easily allow this (or the resulting printed output barely resembles what's shown in the window). 3. I often have as many as 5 books open on my desk...I can recall many days when I'd have 2 volumes of the OS/2 PM Programming Reference, the PM Programming Guide and the Control Program Reference all open at the same time. Granted I had these in electronic form too but it was cumbersome to switch between them and even more so to have them open at the same time (if I wanted to compare things). I have a fairly large work area so I doing this with hardcopy is a snap. (donning my asbestos bodysuit) Jimmie -- Jimmie Mayfield "Climb a little higher jimmie@ccs.uky.edu Find another reason to stay." #include http://www.pa.uky.edu/~mayfield -- Jimmie Mayfield "Climb a little higher jimmie@ccs.uky.edu Find another reason to stay." #include http://www.pa.uky.edu/~mayfield From: pygmy@eskimo.com (Frank Sergeant) Subject: Re: Stack Computer book on-line X-Nntp-Posting-Host: eskimo.com Message-ID: <6jN/xYv1ugHK084yn@eskimo.com> Originator: pygmy@eskimo.com Reply-To: pygmy@pobox.com References: <4th0j3$fd5@optional.cts.com> Date: Mon, 29 Jul 1996 15:30:02 GMT In article <4th0j3$fd5@optional.cts.com>, cwr@cts.com (Will Rose) wrote: > Julian V. Noble (jvn@faraday.clas.Virginia.EDU) wrote: > : 5. It is easy to annotate a book with a low-tech device known > : as a pen. The annotation is permanent. > > Anyone who scribbles on any book is beneath contempt. Under pressure, > I'll concede light pencil annotation. If I owned a _Principia_ manuscript in Newton's hand, I would not write on it either in pencil or ink. Further, I agree it is extremely impolite to mark up a book belonging to someone else, although I might be willing to correct errors in library books lightly in pencil. But, when it comes to my own books, I feel free to mark in them as I please. I even cut a calculus book into chapters some years ago so I wouldn't have to lug the entire monster to class every day. I think books were holy but now they are tools. -- Frank pygmy@pobox.com (permanent) http://www.eskimo.com/~pygmy From: Brad Eckert Subject: Looking for better names for array operations Date: 30 Jul 1996 04:38:56 GMT Message-ID: <4tk3l0$1524@news.goodnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 1.22 (Windows; I; 16bit) I use often use COUNT for something other than what it's name implies. For example: : type 0 ?do count emit loop drop ; In this case, COUNT should probably go by another name. I've been thinking of UNLAY, since it deals with strings. LAY and UNLAY seem like pretty useful primitives. Sample usage: : unlay ( a -- a+1 c ) count ; : lay ( a c -- a+1 ) over c! 1+ ; : type ( a n -- ) 0 ?do unlay emit loop drop ; : cmove ( asrc adest n -- ) 0 ?do swap unlay swap lay loop 2drop ; -LAY and -UNLAY could be similar except index backwards. I don't know what to call versions that would deal with cell-size data. Any suggestions for names? -- Brad From: Chris Jakeman Subject: Re: Manipulating Return Addresses Date: Mon, 29 Jul 1996 20:26:55 +0100 Message-ID: References: <31F76F75.5E13@headwaters.com> X-NNTP-Posting-Host: apvpeter.demon.co.uk MIME-Version: 1.0 In article , "W.Baden" writes >Applications that need Return Stack Manipulations would be better >written in another language. E.g. there are regular expression >packages more powerful and more efficient than anything written in >Forth that can be had for the downloading. There's a challenge! I have no evidence yet that pattern-matching in Forth is more efficient than in conventional languages, but it is certainly different. Given a small set of operators for manipulating Return Addresses, Gordon Charlton's FOSM will compile a pattern and execute it. Conventional languages have to store that pattern as a state machine and interpret that. Sounds less efficient to me ... Perhaps Michael Gassanenko can tell us how BacForth compares in power and efficiency? Bye for now _ _______________________| |_____ Chris Jakeman / _Forth_Interest_Group_| |____/ / /_ __ ______ _ _ | | __ at Peterborough / __/ / / / __ / | | | | | |/ / (a cathedral city / / / / / /_/ / | \_| | | < 80 miles north of London) /_/ /_/ /___ / \____| |_|\_\ Where do you come from? / / ______________/ / United Kingdom Voice +44 (0)1733 346477 /_______________/ Chapter From: jwillard44@aol.com (JWillard44) Subject: Re: multiple entries Date: 30 Jul 1996 01:09:29 -0400 Message-ID: <4tk5e9$hnv@newsbf02.news.aol.com> References: <4ti7h3$sem@hkusuc.hku.hk> Reply-To: jwillard44@aol.com (JWillard44) h9290246@hkuxa.hku.hk (Zsoter Andras) wrote: > Well, you might loose a couple of CPU cycles for the > additional call, but how often does it matter? When you consider that Forth is often used in embedded systems where memory is very limited and clockspeed is ridiculously slow to save power, it may be critical. It takes one less level of stack (and I have seen stacks limited by hardware to 16 bytes), saves a subroutine call for both routines, and saves a return for both routines. Joel in Ogden From: jwillard44@aol.com (JWillard44) Subject: Re: Palmtops and Forth Date: 30 Jul 1996 01:05:14 -0400 Message-ID: <4tk56a$hiv@newsbf02.news.aol.com> References: Reply-To: jwillard44@aol.com (JWillard44) rivie@intergate.daautah.com (Caldera Desktop User) wrote: > AFAIK, HP hasn't built any HP-71s in a long time. They are still available, if you know where to get them. I did a little while ago. From: "Elizabeth D.Rather" Subject: Re: FORTH and TCP/IP Date: Tue, 30 Jul 1996 01:40:29 -0700 Message-ID: <31FDCA7D.30C6@earthlink.net> References: <4tbp5l$617@news.wco.com> <838503830snz@tcontec.demon.co.uk> <838682335snz@mpeltd.demon.co.uk> X-NNTP-Posting-Host: forthinc.demon.co.uk X-Mailer: Mozilla 2.01 (Win95; I) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stephen Pelc wrote: > > In article <838503830snz@tcontec.demon.co.uk> > peb@transcontech.co.uk "Paul E. Bennett" writes: > > In article <4tbp5l$617@news.wco.com> root@pacx.com "root" writes: > > > Gentlemen: I am curious -- Has there been a TCP/IP kernel implemented > > > in/with/for FORTH? My familiarity with the Language (from years ago) > > > leads me to believe that FORTH and TCP/IP would be a rather useful > > > combination. > > As far as I know there are *at least* commercial implementations available > now or real soon now (working prototypes). > Greg Bailey - Athena - available now For info on this contact greg@minerva.com Cheers, Elizabeth -- =============================================== Elizabeth D. Rather 1-800-55-FORTH FORTH Inc. 310-372-8493 111 N. Sepulveda Blvd. Fax: 310-318-7130 Manhattan Beach, CA 90266 http://websites.earthlink.net/~forth "Forth-based products and Services for real-time applications since 1973." =============================================== From: Eberhardt Krueger Subject: Bug in Win32Forth on Win32s Date: Tue, 30 Jul 1996 12:03:58 +0200 Message-ID: <31FDDE0E.5382EC55@RZ.TU-Ilmenau.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (X11; I; Linux 1.2.13 i586) Hi. I downloaded the latest version of Tom Zimmers Win32Forth from Taygeta and installed it. I have to say that this is the coolest Forth I've ever seen. But after playing around a bit I found a bug. It shows this behaviour: The WinView program can be loaded by typing "edit whatever.f" if it is not running. If it is running nothing happens. Same is with the following code entered at the console: Window mieps Start: mieps beepme Not beep comes. Reason: The WM_win32Forth message is handled by the window mieps but the WM_BEEPME is not accepted. ( Same with the ED_OPEN_... stuff.) The numbers are truncated because the are 0x80000 and above. Sadly Win 3.1 is still 16-Bit in the wparam even when running with Win32s. Solution: Change the constants to values lower than 65536. This applies to all ED_... constants and the WM_BEEPME constant. Note for T. Zimmer. It would be nice if you can put this change into the next version. Lars (not Freddy) Krueger mailto: ai108@rz.tu-ilmenau.de URL: http://seba.rz.tu-ilmenau.de/~ai108 From: Eberhardt Krueger Subject: Improvement for Win32Forth Date: Tue, 30 Jul 1996 12:10:27 +0200 Message-ID: <31FDDF93.736FD8E4@RZ.TU-Ilmenau.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.0 (X11; I; Linux 1.2.13 i586) Hi. I have an idea how to improve Win32Forth. The "register-frame-window" word could be splitted in two words. One that fills out structure and one that passes this structure to windows. The result of this is: If you have an appication and/or single window that needs non-default class atrributes and/or a different pointer/background/style you can easily change this without lots of extra code. Note to T. Zimmer: It would be nice if you can put this change into your next version. Lars (not Freddy) Krueger mailto: ai108@rz.tu-ilmenau.de URL: http://seba.rz.tu-ilmenau.de/~ai108 From: Tim Bradshaw Subject: Re: Stack Computer book on-line Date: 30 Jul 1996 11:30:35 +0100 Message-ID: References: <01bb7d0c$b5468d80$c7ace8cd@johnpass> <4ths82$6mt@murrow.corp.sgi.com> <31FCC0F7.488B@informatik.tu-muenchen.de> * Bernd Paysan wrote: > Steve Alexander wrote: >> Also, I believe that I read a few years back that a lot of the raw data >> collected in the 50s and 60s is now useless since the tape formats (probably >> 80-column card images) can't be interpreted without the original computer >> programs. Don't quote me on this, I can't remember the source... > It's more likely that the information on the tape is completely > gone. I can't imagine any higher level of cryptography applied to > these tapes (Read Solomon would be difficult enough), so even if the > character set, the bit size and the format is unknown, it can be > easily retrieved using some cryptanalytic methods. Yes but what you end up with is something like a string of decimal numbers which once meant something to someone but no one can remember what it was and what was which. And unless you know lots of details of the equipment they came from and the program that used them, you have a very hard problem. --tim From: rstevew@armory.com (Richard Steven Walz) Subject: Re: Stack Computer book on-line Date: Mon, 29 Jul 96 8:36:13 PDT Message-ID: <9607290836.aa25120@deepthought.armory.com> References: In-Reply-To: Status: R Originator: rstevew@armory.com Dear Julian, I LIKE books, they are my friends! At this point we ARE a bit over-JPEG'd, over-PDF'd, and a bit like trying to see the world through a monitor that's too small! I would rather be able to wear a pair of glasses that correct my vision, but also can pop up a display of any page of any of my books I choose, focused in space just as it really does look, and for it to search for the thing I want without even damned page flipping! I want it to keep my places, and allow me to manipulate it while doing something else in front of me at the workbench, and magnify my workbench view as I wish as well, while keeping my book up and ready to pop into view when I like, and off to one side, and have several such books there ready to pop up and surround my work area in my visual field!!! Windows in mixed Real and VR, and focused and lit as a gentle reading lamp would show it, and even clearer than that, as I know I shift books in my hands to optimize the light, and that's a hassle!! While I think your remarks below are well said, I do think we shall soon have a small and flat means of storing many books at once, as visibly and virtually as tactile as a paper book. It will turn pages as fast, and keep your places when marked, and also keep your glossings for your own copy as ready and at hand as looking in a margin, maybe better! And you're quite right that we are NOT there yet, and Cliff Stoll is as right in that respect, but I think he's a bit of a grand- stander since his earlier claim to fame, and he is too frenetic for me to actually watch for long without wishing to call him a neurologist and quickly!!! ;-> Perhaps he SHOULDN'T use computers, till they stabilize his meds at LEAST!! ;-) Any assertions at this point that ANYTHING will be lost from here on out that "should" not be, through media incompatibility, is a genuinely ignorant argument, ignorant of how universal the binary format is and how easily transported. Yes, some folks didn't take care of the early stuff and it IS hardER to find, but now it IS, as we speak, being put on CD-ROM and on other long term storage, even INCLUDING data originally developed with punch tape readers and Hollerith card readers!! Such an assertion is merely vacant of knowledge of what is being done. Software back to the mainframes of the 60's is still available and even software emulators FOR those old machines are or have been written! And the source code accompanies! In the early days of humans, those we call "prehistory", because they either didn't write it down very well or very much, or at all, the situation was similar. They didn't know they HAD anything really NEW and a GOING THING to WRITE about that often!! We have understood that now, and storage media is getting MORE robust and even cheaper as we speak! Masters of CD-ROMs made with hardened metals don't deteriorate 100th as much as even the polycarbonate in CD-ROMs. And they are good for MUCH longer than ferrous magnetic oxides! And your much vaunted "paper" eats the rain forests, and you haven't even persuaded them to make it non-acidic yet, so that it doesn't self-destruct on schedule!! Those who tout books they can hold in their hands had better discover Tyvek!! It makes a MUCH more durable "paper"!! Maybe even a lifetime of 100,000 years if protected!! But the memory of binary will persist and grow FAR faster than the supply of petroleum to write it on those beautiful white heat-fused mats of polyester thread! The writings of humanity will double now first every five years and then faster and faster!! We'll need countless infobots to search through it for us! Also, Stoll's prating about supposed insipidity in the computer medium only extends truthfully into the few areas that our culture tends to always crap-up anyway, whatever the medium or level of technology involved. From skateboards to gang apparel! While we may need a greater involvement of physical exercise, it is even now being imported into computer gaming and VR!! No one will be forced to be some "couch potato" who doesn't prefer that anyway, be it in a cave in France 30,000 years ago working at being the best flint knapper and arrow maker and elder-cum-babysitter you ever saw, just so he could stay home and putter around!!, or whether it be on-line for 10 hours a day procuring and distilling information as a techno-archivist in the 21st century!! And not just that: TRY to tell me that a VR stereo viewer can't put ANY kind of "book" in your "hands" that YOU might like!! It's the same as trying to tell me we can't open the skull for an operation because it's "against God" or "might let the person's 'spirit' escape"!! Cliff Stoll would have raled at Gutenburg for printing dispensations and indulgences, and he would have been right, but NOT about the printing press at ALL!!! And if you really wish to join him, you'll be regarded as "silly" later historically, precisely to the degree that you do!! And if you trusted valued programs to punch-tape and didn't keep your own punch-tape reader when they were as cheap as a model 31 teletype at the Goodwill for $5, which I used for two years at home in 1982, until I could afford a terminal and disk drives, then you ARE silly, and likely deserve what you get!! There are still PLENTY of punch-tape and card readers in use at professional archivists!! *IF* you kept your paper tape!!! They also STILL sell in the back of hobby magazines all over North America and Europe, NEW designs of them for that very purpose!! As for your attempt to adapt to faultless "multi-tasking" with a couple computers, Julian, pick up a dozen more at K-Mart in a few years and try it again!!! They will be the size of a magazine, cost about the same, and download into them whatever you want! THEN try holding the stack of them in your lap or hang them about your workspace and see how it goes!! I think you'll see what I mean! You're judging the wheel before the axle and hub are perfected, or the tubeless tire!! And remember, Julian, that even candles go out when spent, as do batteries, power plants, forests, and life! And the sun continues to "go" up and down, like it or not! Our CHOICE is to reduce failures such as that to vanishingly small occurences!! That IS the human drive!! Your problem seems not so much that you're some violent Luddite, ready to turn over steam-driven Jacquard card-looms, but that you simply don't quite really believe yet that humans were "intended" to... "Fly!". :-> Take care... ...and remember to back-up!!... WHILE going Forward! ;-> -Richard Steven Walz rstevew@armory.com ----------------------------------------------------------------- In article you write: >jvn@faraday.clas.Virginia.EDU writes: > > [ remarks re: return of copyright deleted ] > >> Thanks to Phil Koopman for putting his book on line. However, >> as Cliff Stoll notes in "Silicon Snake Oil", on-line documents >> are not as useful as hard copy ones. > >My reference to "Silicon Snake Oil" apparently touched a nerve. >I haven't received so many flames since the time I died and went >to Hell. (in a handbasket, of course :-) > >To avoid being classified as a Luddite (look it up if you didn't >pay attention in History 101) of the Web, let me amplify the >above remark. In the following, "book" refers to ink on paper >pages sewn or glued together in sequence. > > 1. A book is lighter and more portable than the smallest > current machine that can access the Web. > > 2. A book is still readable by candlelight, when the power > fails and the battery dies. > > 3. The print on a cheaply printed book page is far more > legible than the output on the highest resolution display > that is currently available to mere mortals. It is much > easier on the eyes. > > 4. Unless one is connected to the server by a very high speed > line, cross-referencing by flipping a book page is far > faster than the electronic analogue. > > 5. It is easy to annotate a book with a low-tech device known > as a pen. The annotation is permanent. > > 6. When one reads a technical treatise ("Scientific FORTH", > e.g.) in book form, while implementing its ideas on > a computer, one does not lose one's place in a crash. > > 7. Sitting with a book in one's lap does not waste expensive > bandwidth on the network. > > 8. A book written 50 years ago may still be read. Many of > my programs from the 1970's and 1980's cannot be read since > their media --punched tapes, punched cards, magnetic tapes-- > are now obsolete. Will CD-ROMs or magnetic disks of current > type become as unreadable as 8" floppies now are? > >If anyone wishes to refute the above points (politely--calling me an old >fogey is neither a refutation nor polite, no matter how true it might be), >I would be interested to read their views. > >It seems to me that the individuals who flamed the hottest and most >incoherently have not considered the problems associated with on-line >books accessed by 28.8Kb modems. I suspect they do not have to pay >for access time, but receive it gratis from their institutions. > >I really have tried to use on-line documentation (on my own machine) >in a multitasking system and with two separate computers. Even the >latter is not as good as having the book next to the machine. If >these observations (which I was glad to see Stoll agreed with) make >me a Luddite, so be it. > >-- >Julian V. Noble >jvn@virginia.edu -- - Lots of New Electronics Stuff!! 450 Files / 22 Dirs ( Full Mirror ==> * ) -Steve Walz rstevew@armory.com ftp://ftp.armory.com:/pub/user/rstevew * Italy: ftp://ftp.cised.unina.it:/pub/electronics/mirrors.ftp.armory.com * USA: ftp://ieee.cas.uc.edu: Don't bother! Not keeping up their Mirroring! From: Brad Rodriguez Subject: Re: Stack Computer book on-line Date: Tue, 30 Jul 1996 07:27:52 -0700 Message-ID: <31FE1BE8.54AC@headwaters.com> References: <31f61e27.6475492@usenet.interramp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Win16; I) Julian V. Noble wrote: > Perhaps with enough interest Phil would let FIG reprint his book, > as Leo Brodie has done with "Thinking Forth". If the price were > moderate, most of us would acquire "Stack Machines" rather than > go to the trouble of downloading and making hard copy to read > in our spare time, and Phil could get some royalties. An excellent suggestion. I'm sure the original price of $60 was prohibitive to many prospective purchasers. -- Brad Rodriguez bj@headwaters.com Computers on the Small Scale This brain for rent -- inquire within. Contributing Editor, The Computer Journal... http://www.psyber.com/~tcj Director, Forth Interest Group........... http://www.forth.org/fig.html From: Tom Zimmer Subject: Re: Improvement for Win32Forth Date: Tue, 30 Jul 1996 08:26:43 -0600 Message-ID: <31FE1BA3.21E@ix.netcom.com> References: <31FDDF93.736FD8E4@RZ.TU-Ilmenau.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Tue Jul 30 6:25:36 AM PDT 1996 X-Mailer: Mozilla 2.01 (Macintosh; I; PPC) Eberhardt Krueger wrote: > > Hi. > > I have an idea how to improve Win32Forth. > The "register-frame-window" word could be splitted in two words. > One that fills out structure and one that passes this structure to > windows. > The result of this is: > If you have an appication and/or single window that needs non-default > class atrributes and/or a different pointer/background/style you can > easily change this without lots of extra code. > > Note to T. Zimmer: It would be nice if you can put this change into > your next version. Sounds interesting to me, I will look at it. Tom Zimmer From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Re: RFI: different routines for compilation & interpretation Date: 30 Jul 1996 15:00:57 GMT Message-ID: <4tl839$5a8@news.tuwien.ac.at> References: <4siu7v$jko@news.tuwien.ac.at> <4sn81d$t3h@sjx-ixn3.ix.netcom.com> In article <4sn81d$t3h@sjx-ixn3.ix.netcom.com>, JEThomas@ix.netcom.com (Jonah Thomas) writes: |> I didn't quite get it that way, though you might be right. If a program |> needs the S" behavior to be selected at interpretation time, then it has a |> dependency on that. And if it needs the behavior to be selected at execution |> time, it has a dependency on _that_. Maybe either one could be standard with |> an environmental dependency? I think that the difference between a non-standard program and a standard program with environmental dependences is that in the latter case the dependences are documented. In the extreme, you can call a C program a standard Forth program with an environmental dependency that it should be interpreted according to the C standard.:-) - anton -- M. Anton Ertl Some things have to be seen to be believed anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html From: anton@a0.complang.tuwien.ac.at (Anton Ertl) Subject: Multi-exit loop (Was: Is using mult Exits bad pgrming) Date: 30 Jul 1996 15:26:14 GMT Message-ID: <4tl9im$5a8@news.tuwien.ac.at> References: <4r2c5p$o89@hkusuc.hku.hk> <4r2jqi$km3@newsbf02.news.aol.com> <4sjevm$187@zeus.tcp.co.uk> <31EF9C3D.2B6F@inlink.com> <4so93r$ddp@dfw-ixnews6.ix.netcom.com> In article <4so93r$ddp@dfw-ixnews6.ix.netcom.com>, JEThomas@ix.netcom.com (Jonah Thomas) writes: |> ... BEGIN ... WHILE ... WHILE ... WHILE ... REPEAT ... ELSE ... THEN ELSE ... |> THEN ; While this is certainly useful, I find it hard to follow which ELSE or THEN belongs to which WHILE. I'd rather write it like this: BEGIN ... IF ... AHEAD [ 1 CS-ROLL ] THEN [ 1 CS-ROLL ] ... IF ... AHEAD [ 1 CS-ROLL ] THEN [ 1 CS-ROLL ] ... IF ... AHEAD [ 1 CS-ROLL ] THEN [ 1 CS-ROLL ] ... AGAIN THEN THEN THEN or so. Of course, I would hide the low-level control-structure words behind new high-level words, e.g.: START ... IF ... LEAVE-LOOP ... IF ... LEAVE-LOOP ... IF ... LEAVE-LOOP ... END (yes, the names may not be optimal). These words are defined like this: variable count-leaves : START ( -- n dest ) count-leaves @ 0 count-leaves ! POSTPONE begin ; immediate : LEAVE-LOOP ( dest orig1 -- orig2 dest ) 1 count-leaves +! POSTPONE ahead 1 cs-roll POSTPONE then 1 cs-roll ; immediate : END ( n orig1 ... orign dest -- ) POSTPONE again count-leaves @ 0 ?DO POSTPONE then LOOP count-leaves ! ; immediate - anton -- M. Anton Ertl Some things have to be seen to be believed anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen http://www.complang.tuwien.ac.at/anton/home.html From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Re: multiple entries Date: 30 Jul 1996 15:35:29 GMT Message-ID: <4tla41$pan@sjx-ixn6.ix.netcom.com> References: <4te5j4$opk@navajo.gate.net> X-NETCOM-Date: Tue Jul 30 8:35:29 AM PDT 1996 In <4te5j4$opk@navajo.gate.net> spc@gate.net (Sean 'Captain Napalm' Conner) writes: >>: RED ." Red plays first. " >> BEGIN Red-plays >> 0 IF >>; >>: BLUE ." Blue plays first. " >> THEN Blue-plays >> AGAIN >>; > Just hope that the next fellow to come along to maintain your code can >catch on to what you're doing and NOT insert a definition between RED and >BLUE. Or what happens if GREEN needs to be added? Before RED? Between? >After BLUE? It's maintenance problems that possibly made this style go >out of favor. You've reminded me of one of my peeves about this kind of discussion. Not that you're wrong. It's that maintenance is an open-ended problem. We have interactive systems to program with. If you want to find out what the computer thinks you mean, you can ask it and see. Quick and easy. If you want to find out what the guy who's going to maintain your code thinks you mean, then good luck! He might not have been hired yet. Hell, he might not have been born yet. Hard to tell what he'll understand easily. One approach to writing maintainable code is to write stupid code. Make sure everything is clear and obvious. : GET-PRICE-FIELD-FROM-ITEM#-FIELD ( addr1 -- addr2 ) CELL+ ; : GET-PRICE-FROM-PRICE-FIELD ( addr -- price ) @ ; (Incidentally, I think sometimes long descriptive names do help more than comments, sometimes, because when the function changes out from under the name you confuse yourself and remember to change it. In the heat of the deadline it's easy to forget about changing comments. Of course, this only applies to people who sometimes fail to go back and revise their comments. But back to the point.) Trying to write maintainable code leads to code which is pedestrian. A long "clear" routine might seem more maintainable than a clever short one. A mediocre algorithm may be more obvious than a more efficient one. The dead hand of tradition. The return stack manipulations are a case in point. By all accounts they provide great power. The problem is that they're hard to understand. Should we look at the problems and find ways to make them easier? Find tools that make interactive testing easy? Notation that makes it easy to follow the logic? Harness the power? In the long run that's obviously the best thing. But in the short run, the thing to do is to simply avoid the techniques because they aren't maintainable. If you need to do something that needs that power, you can always use some language that provides it. In a way, this is eating the seed corn. "I don't have time to breed better varieties, I'm too busy getting a crop in. And if you come up with something new I won't use it anyway, it isn't what I'm used to." Anyway, maintenance is an unsolved problem, and Forth techniques don't give us any help with it. If Chuck Moore had wanted his code to be maintainable he'd have written it in Fortran. But then, if he hadn't found a smart person to do documentation and cleanup for him, his code would have been unmaintainable. It's a puzzle. From: aph@phal.cygnus.co.uk (Andrew Haley) Subject: Re: Is using mult Exits bad pgrming Date: 30 Jul 1996 10:05:30 GMT Message-ID: <4tkmpa$3gf@majipoor.cygnus.com> References: <4r2c5p$o89@hkusuc.hku.hk> <6DbcBKtb7QB@business.forth-ev.de> <4tj4iq$h4k@nadine.teleport.com> znmeb@teleport.com wrote: : Wolfgang Allinger (All@business.forth-ev.de) wrote: : : In forth words I use a lot of 'IF ... EXIT THEN' in the beginning to : : handle the special cases. A logic analyser is nearly useless in forth, so : : I do what it makes it easier for me. : Correct me if I'm wrong, but doesn't a logic analyzer operate by : sampling the busses and displaying instruction and data addresses? If : so, I'd think it would be possible to write your Forth code in a manner : that catered to this. That's not really the point. If you use Forth to develop embedded applications, a logic analyzer is redundant: you use interactivity instead of staring at traces. Interactivity is cheaper and more productive. Andrew. From: znmeb@teleport.com () Subject: Re: Stack Computer book on-line Date: 30 Jul 1996 15:59:14 GMT Message-ID: <4tlbgi$rob@nadine.teleport.com> References: Tim Bradshaw (tfb@aiai.ed.ac.uk) wrote: : Yes but what you end up with is something like a string of decimal : numbers which once meant something to someone but no one can remember : what it was and what was which. And unless you know lots of details : of the equipment they came from and the program that used them, you : have a very hard problem. : --tim In the case of seven-track tapes, you can find books :-) describing the exact recording techniques and character coding in any decent-sized university library and many large public ones. If the tapes were *binary*, you'd need to know a little more, such as the kind of computer that wrote them. In the text case, the IBM standard was the dominant one and you would probably be safe assuming it. -- znmeb@teleport.com (M. Edward Borasky) http://www.teleport.com/~znmeb Coming soon to a theatre near you -- the remake of "War With The Newts"! From: jvn@faraday.clas.Virginia.EDU (Julian V. Noble) Subject: Re: Stack Computer book on-line X-Nntp-Posting-Host: faraday.clas.virginia.edu Message-ID: References: <31FD16C8.588B@gr.hp.com> Date: Tue, 30 Jul 1996 16:11:55 GMT Mass response to some of the replies, public and private: I agree that CD-ROMs are a more compact way to store information. I agree that large compendia--big reference manuals like the Windows function library, the Oxford English Dictionary, the works of Freud, everything that has ever been written about Shakespeare--are more convenient on-line, even with today's primitive technology. I use them myself. I agree that no technology is perfect from the outset. (In fact, I am currently writing a book about the effect of technology on the course of history, so I would HAVE to believe that.) (-; The point is that _current_ technology available to the masses does not yet compete with the ordinary, primitive, printed book. So neither the "paperless office" nor the virtual library are effective realities. I could have mentioned that the best color computer graphics still does not equal the best color reproductions (which are themselves not really faithful) of art, etc. I am sure that someday books will be available in formats that exceed the capabilities of print at a lower price. That day does not seem close, although I do not place it 10,000 years in the future as Frank Herbert did. I will be glad enough to see it in my (remaining) lifetime. I STILL think a book like Phil Koopman's is better in print than on line, even though he himself might not agree. Regards to (almost) all who commented and replied privately. -- Julian V. Noble jvn@virginia.edu From: Tom Zimmer Subject: Re: Bug in Win32Forth on Win32s Date: Tue, 30 Jul 1996 08:24:58 -0600 Message-ID: <31FE1B3A.ACE@ix.netcom.com> References: <31FDDE0E.5382EC55@RZ.TU-Ilmenau.DE> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Tue Jul 30 6:23:51 AM PDT 1996 X-Mailer: Mozilla 2.01 (Macintosh; I; PPC) Eberhardt Krueger wrote: > > Hi. > > I downloaded the latest version of Tom Zimmers Win32Forth from Taygeta > and installed it. > I have to say that this is the coolest Forth I've ever seen. > But after playing around a bit I found a bug. It shows this behaviour: > > The WinView program can be loaded by typing "edit whatever.f" if it is > not running. If it is running nothing happens. This could be related to not having enough memory, or as you suggest later, it could be related to a message number greater than 0xFFFF. I thought this had been fixed in version 3.2. I will check it. > Same is with the > following code entered at the console: > > Window mieps > Start: mieps > beepme > > Not beep comes. > > Reason: The WM_win32Forth message is handled by the window mieps > but the WM_BEEPME is not accepted. ( Same with the ED_OPEN_... stuff.) > The numbers are truncated because the are 0x80000 and above. Sadly > Win 3.1 is still 16-Bit in the wparam even when running with Win32s. > > Solution: Change the constants to values lower than 65536. This applies > to all ED_... constants and the WM_BEEPME constant. I thought I had fixed that in the latest release, version 3.2. Perhaps not. Again, I will check it out. Thank you for the report. It would be nice if those nasty bugs could be eliminated forever, bug they never seem to quite go away completely. We'll just have to keep plugging away I guess. Tom Zimmer From: wilbaden@netcom.com (W.Baden) Subject: Re: Manipulating Return Addresses Message-ID: References: <31F76F75.5E13@headwaters.com> Date: Tue, 30 Jul 1996 17:04:40 GMT Chris Jakeman (cjakeman@apvpeter.demon.co.uk) wrote: : There's a challenge! I have no evidence yet that pattern-matching in : Forth is more efficient than in conventional languages, but it is : certainly different. Given a small set of operators for manipulating : Return Addresses, Gordon Charlton's FOSM will compile a pattern and : execute it. Conventional languages have to store that pattern as a : state machine and interpret that. Sounds less efficient to me ... A String Matching Package in Forth is a means, not an end. What is needed is a Forth incarnation of de-facto standard regular expression manipulation. This may well use a string matching package in Forth, but such a package in Type 2 or Type 3 Forth will not equal the performance of already-written C packages, e.g., Henry Spencer's REGEXP or Tatu Ylonen's REGEXPR.Ê (I use the latter.) It is trivial to incorporate these into Type 2 or Type 3 Forth. Most uses of regular expressions are ad-hoc throw-away. Here is my next-to-last use. I wanted to replace 10 followed by one or more blanks at the begining of lines by 9 followed by a single blank. This is the Forth Editor command I used. ALL F ^10 +% R 9 % The last use was similar. I wanted to replace a number at the beginning of lines, followed by one or more tabs or spaces, with the number, a colon, and a single tab. ALL F ^([0-9]+)[ ]+% RE R \1: % How do I do these with FOSM? -- Procedamus in pace. Wil Baden Costa Mesa, California Type 1 Forth: Machine language for a hardware Forth engine. Type 2 Forth: Toolkit for a software Forth engine. Type 3 Forth: Guest of a host. From: skip@taygeta.com (Skip Carter) Subject: Re: Manipulating Return Addresses Date: 30 Jul 96 19:11:56 GMT Message-ID: <31fe5e7c.0@news.itvcorp.com> References: <31F76F75.5E13@headwaters.com> In article , wilbaden@netcom.com (W.Baden) writes: ( .... among other things that were snipped out ... ) |> Local Variables. |> ================ |> |> As I've written before, Forth with local variables is Tiny C |> with postfix operators. |> |> With short definitions that should be typical of Forth, local |> variables are distracting. An application that "needs" local |> variables would be written better in another language. As |> almost all good Forth definitions have no more than three |> arguments, local variables don't do much. Local variables |> have too much overhead for too little return. I tend to use local variables in two places: 1 -- to reduce the amount of stack gymnatics 2 -- to reduce problems with namespace collisions, especially for reentrant code where global variables are not practical |> |> What would be valuable would be local definitions - definitions |> local to a package of definitions. WORDLIST can done this but |> awkwardly. As I wrote above, strangely missing from the Standard |> is the ability to behead definitions easily. YES, YES, YES!!!! I'd love to see this done right! It would make my reason #2 above much less necessary. |> |> Exception Handling. |> =================== |> |> In Standard Forth this means CATCH-THROW. Is CATCH-THROW |> really that much better than vectoring ABORT ? The examples |> of actual use of CATCH-THROW that I've seen introduce dynamic |> spaghetti-code into the application. |> Here is an example of code where I use exception handling that IMHO is clear and where ABORT is not suitable. (this is an excerpt from my EMACS Forth TAGS generator) : ( -- ) $filename R/O OPEN-FILE THROW \ try to open a file for reading .... stuff to do if the file open succeeds... ; : process_file ( -- ) ['] CATCH IF ." unable to open file: " $filename TYPE CR THEN ; : tags ( ---- ) \ generate EMACS tags for named file list .... BEGIN next_file \ get next file name from list, store it at $filename WHILE process_file REPEAT ... ; I DO NOT want to ABORT if the file open fails (maybe I mis-typed the name), but instead to go on to the next file in the list and process that. |> Memory Allocation. |> ================== |> |> The functions of ALLOCATE-FREE-RESIZE are crucial in the major |> profane languages, but in Forth we've always had ALLOT. |> |> Would those who have implemented ALLOCATE-FREE-RESIZE |> tell me what applications you have used them for? |> They seem useful for some specialized applications, |> but not for general applications, as they are in the major |> profane languages. |> Sometimes its nice to be able to FREE space that has been previously ALLOCATED so that the space becomes available for other uses, especially in a multi-tasking application with tasks that are dynamically created and destroyed. I have also defined special versions of ALLOCATE that use special memory areas, like shared memory (of course, I could have just implemented a word like ALLOCATE-SHARED for this). -- Everett (Skip) Carter Phone: 408-641-0645 FAX: 408-394-5561 Taygeta Scientific Inc. INTERNET: skip@taygeta.com 1340 Munras Ave., Suite 223 UUCP: ...!uunet!taygeta!skip Monterey, CA. 93940 WWW: http://www.taygeta.com/skip.html Date: 30 Jul 1996 09:31:00 +0100 From: joerg.plewe@jpsforth.forth-ev.de (Joerg Plewe) Message-ID: <6DrJujFddNB@jpsforth.forth-ev.de> References: <4tbp5l$617@news.wco.com> <838503830snz@tcontec.demon.co.uk> Subject: Re: FORTH and TCP/IP #On 27 Jul 96, peb@transcontech.co.uk (Paul E. Bennett ) wrote: > In article <4tbp5l$617@news.wco.com> root@pacx.com "root" writes: > > > Gentlemen: I am curious -- Has there been a TCP/IP kernel > > implemented in/with/for FORTH? My familiarity with the Language > > (from years ago) leads me to believe that FORTH and TCP/IP would be > > a rather useful combination. > > awaiting comments. All flames forwarded to packet multipliers. > > Skip couldn't recall when I asked him last a few months back and I do > not seem to have seen anything of it yet. We might have to do the > research of the requirements and produce some code for it yet. Hi! In fact I already did some IP-stuff in (ANS-)Forth. Based on the packet driver interface I (so far) implemented a stack up to the state where single IP packets can be sent to and received from the net. That means that ARP + ARP cache with all this timeout stuff already works, it receives and sends (some) ICMP messages, knows about default router, netmask, ... You are right that this works really great with Forth. The goal of my package is to AVOID copying of buffers to make it fast on controllers (68k is the target). Now the bad point: I did all this as a contract work, so I cannot contribute it to the community (but I will take a look at the contract again, maybe I am wrong). But sure I could give some hints about how I did it. - Joerg \ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ \ _/ Joerg Plewe JPS@Forth-eV.de _/ \ _/ Haarzopfer Str. 32, D-45472 Muelheim, Germany +49 (0)208 497068 _/ \ _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/ \ I have the Pentium bug. And I like it! From: ehp@ear.co.at (Ewald Pfau) Subject: Multi-exit loop (Was: Is using mult Exits bad pgrming) Message-ID: <838766049.AA00407@ear.co.at> Date: Wed, 31 Jul 1996 01:28:26 +0100 X-FTN-To: Anton Ertl (Jet Thomas:) |> ... BEGIN ... WHILE ... WHILE ... WHILE ... REPEAT ... ELSE ... THEN ELSE ... |> THEN ; (Anton Ertl:) AE> BEGIN AE> ... IF AE> ... AHEAD [ 1 CS-ROLL ] THEN [ 1 CS-ROLL ] AE> ... IF AE> ... AHEAD [ 1 CS-ROLL ] THEN [ 1 CS-ROLL ] AE> ... IF AE> ... AHEAD [ 1 CS-ROLL ] THEN [ 1 CS-ROLL ] AE> ... AE> AGAIN THEN THEN THEN There seems to be a specific dialect for indenting: (stuff... flag) IF (stuff... flag) IF THEN . THEN Pairs are not that easily being parsed this way. Replace the above with: (stuff... flag) IF (stuff... flag) . IF . THEN THEN After this, indenting comes with loops. BEGIN (stuff.. flag) WHILE (stuff.. flag) UNTIL THEN By this, the CS-ROLL (in WHILE) is hidden, so two jumps have to be comprehended at one sight. It would be: BEGIN . WHILE UNTIL . THEN It may be ignored or not. For multiple loop-exits (avoiding module-exits), each following WHILE is indented. Don't ignore the CS-ROLL, so: BEGIN . WHILE . . WHILE . . . WHILE UNTIL . . . . . THEN . . THEN . THEN Ignore the CS-ROLL, so: BEGIN WHILE . WHILE . . WHILE . . UNTIL . THEN THEN Just by indenting, more complex situations may become clear. Has any other programming environment the capability to overlap loops? BEGIN . BEGIN [ 1 CS-ROLL ] WHILE [ 2 CS-ROLL ] . WHILE [ 2 CS-ROLL ] UNTIL . UNTIL [ 1 CS-ROLL ] THEN . THEN Instead, Forth has definitely no GOTOs. _Only_ count the C-stack contents for checking. Just _look_ at it for comprehending what happens. Do not count. The graphics should make it clear: This is two loops. Don't care for low level irritations... Some craftmanship is involved: Insert the CS-ROLLS. Not all books are written as trivial as the maintime TV news suggest. A lot of execution flows will be controlled by more than one event. Many of them _are_ structured, but are not trivial. Why ressort to a state machine, if it is structured? A flow-graphics as above may show clearly what happens. Thanx to the one who introduced the CS-PICK and -ROLL into Forth, or but the SO and STILL as it has been named in a previous 'Basis' text (hope I got the names right). Ewald From: wilbaden@netcom.com (W.Baden) Subject: Re: Multi-exit loop (Was: Is using mult Exits bad pgrming) Message-ID: References: <4r2c5p$o89@hkusuc.hku.hk> <4r2jqi$km3@newsbf02.news.aol.com> <4sjevm$187@zeus.tcp.co.uk> <31EF9C3D.2B6F@inlink.com> <4so93r$ddp@dfw-ixnews6.ix.netcom.com> <4tl9im$5a8@news.tuwien.ac.at> Date: Wed, 31 Jul 1996 00:07:23 GMT Anton Ertl (anton@a0.complang.tuwien.ac.at) wrote: > These words are defined like this: > [...] "It's vain to do with more what can be done with fewer." This is why I keep BUT around. : BUT 1 CS-ROLL ; IMMEDIATE CASE BEGIN ... IF ... ELSE BUT ... IF ... ELSE BUT ... IF ... ELSE BUT ... AGAIN THENS -- Procedamus in pace. Wil Baden Costa Mesa, California From: Tom Zimmer Subject: Re: Manipulating Return Addresses Date: Tue, 30 Jul 1996 22:12:57 -0600 Message-ID: <31FEDD49.488@ix.netcom.com> References: <31F76F75.5E13@headwaters.com> <31fe5e7c.0@news.itvcorp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-NETCOM-Date: Tue Jul 30 10:11:50 PM CDT 1996 X-Mailer: Mozilla 2.01 (Macintosh; I; PPC) Skip Carter wrote: > > In article , wilbaden@netcom.com (W.Baden) writes: > > ( .... among other things that were snipped out ... ) > > |> Local Variables. > |> ================ > |> > |> As I've written before, Forth with local variables is Tiny C > |> with postfix operators. > |> > |> With short definitions that should be typical of Forth, local > |> variables are distracting. An application that "needs" local > |> variables would be written better in another language. As > |> almost all good Forth definitions have no more than three > |> arguments, local variables don't do much. Local variables > |> have too much overhead for too little return. > > I tend to use local variables in two places: > > 1 -- to reduce the amount of stack gymnatics > > 2 -- to reduce problems with namespace collisions, especially > for reentrant code where global variables are not practical > |> > |> What would be valuable would be local definitions - definitions > |> local to a package of definitions. WORDLIST can done this but > |> awkwardly. As I wrote above, strangely missing from the Standard > |> is the ability to behead definitions easily. > > YES, YES, YES!!!! I'd love to see this done right! It would > make my reason #2 above much less necessary. You may not have had time to look at it, but the OOP implementation in Win32Forth (ported from NEON) provides these local definitions very well with the code example below. ----- non-functional code example ------------------------------------------ \ STACK-WINDOW is the public object :Object STACK-WINDOW r paint-the-screen r> SelectObject: dc drop \ restore the font paint-the-title ;M :M StartSize: ( -- width height ) \ starting window size 100 200 ;M ;Object From: wilbaden@netcom.com (W.Baden) Subject: Re: Manipulating Return Addresses Message-ID: References: <31F76F75.5E13@headwaters.com> <31fe5e7c.0@news.itvcorp.com> Date: Wed, 31 Jul 1996 02:27:58 GMT Skip Carter (skip@taygeta.com) wrote: : Here is an example of code where I use exception handling : that IMHO is clear and where ABORT is not suitable. : [snip] Thanks to Skip Carter for examples of how he uses Local Variables, CATCH-THROW, and ALLOCATE. I have no disagreement with his use. IfÊthey work for him, that's good enough. However I would like to know what's the problem with the following-- : process_file ( -- ) $filename R/O OPEN-FILE IF \ try to open a file for reading ." unable to open file: " $filename TYPE CR ELSE .... stuff to do if the file open succeeds... THEN ; : tags ( ---- ) \ generate EMACS tags for named file list .... BEGIN next_file \ get next file name from list, store it at $filename WHILE process_file REPEAT ... ; From: Bill Zimmerly Subject: Re: Is using mult Exits bad pgrming Date: Tue, 30 Jul 1996 23:00:09 -0500 Message-ID: <31FEDA49.1F5E@inlink.com> References: <4r2c5p$o89@hkusuc.hku.hk> <4r2jqi$km3@newsbf02.news.aol.com> <4r303a$761@hkusuc.hku.hk> <31E83BF4.4EC5@amresearch.com> <31E9E1C5.74BF@forth.com> <4t1e4f$b9q@news.goodnet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01Gold (WinNT; I) CC: billz@inlink.com Brad Eckert wrote: > > bernd@paysan.modem.informatik.tu-muenchen.de (Bernd Paysan) wrote: > [snip] > >Complicated state machines should be handled with a state machine > >generator, thus a dispatch routine that goes through a table. As Forth > >is a very extensible language, it is not too hard (compared with the > >rest of the problem) to build such a state machine generator. I saw > >something like this in ComForth for Windows, which has "WHEN"-Lists > >for event processing. In fact, a state-machine generator could use > >such "WHEN"-lists to generate the state machine. E.g. you say > > > >:noname keep-card ." Your card is kept because " .reason cr > > ." Please contact your credit institute" cr terminate ; > > 3-times-pid-wrong WHEN card-is-locked OR-WHEN > > > >:noname start-transaktion; > > pid-ok WHEN > > > >:noname output-money ; > > transaktion-ok WHEN > >-- > >Bernd Paysan > >"Late answers are wrong answers!" > >http://www.informatik.tu-muenchen.de/~paysan/ > > Well, that's a really cool idea. I envision WHEN as being a defining > word that would BL WORD its argument from the input stream. Is a state > machine lexicon available on taygeta? Otherwise, what other words would > be useful? I suppose :STATEMACHINE and ;STATEMACHINE could begin > and end the tables, and would go through the table until it finds > a true condition or hits the end of the table. Or am I way off? > > -- Brad I agree with Brad, that *is* a cool idea...it's too good an idea to not impliment under Win32For...I think I'll work on it and get back in a few weeks... - Bill -- \\\|/// \\ ~ ~ // (/ @ @ /) --------------oOOo-(_)-oOOo--------------------------- William B. Zimmerly (Bill) - Systems Research & Development Manager / Webmaster General American Life Insurance Company, Inc. Amateur Radio Call: KA0YKO Email Address: billz@inlink.com Home Page Address: www.inlink.com/~billz ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._ From: Bill Zimmerly Subject: Re: Is using mult Exits bad pgrming Date: Tue, 30 Jul 1996 23:36:39 -0500 Message-ID: <31FEE2D7.7785@inlink.com> References: <6DS5A4LGCHB@malente.forth-ev.de> <4t8sfd$cg4@nadine.teleport.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01Gold (WinNT; I) CC: billz@inlink.com znmeb@teleport.com wrote: > ...[snip] > ... > 2. I rather like the Edsger Dijkstra guarded command syntax as developed > in "A Discipline of Programming". Now *there's* a book that's crying > out to be translated into Forth! I'm sure by now someone has > translated his *two* control structures into Forth -- I didn't see it > in my indexes of Forth Dimensions or FORML proceedings, though. If > no one has done it, I might be persuaded to use the ANS > "roll-your-own-control-structure" words (CS-ROLL, CS-PICK, AHEAD) to > do a sequentrial implementation without Dijkstra's non-deterministic > semantics. Excellent suggestion! - Bill -- \\\|/// \\ ~ ~ // (/ @ @ /) --------------oOOo-(_)-oOOo--------------------------- William B. Zimmerly (Bill) - Systems Research & Development Manager / Webmaster General American Life Insurance Company, Inc. Amateur Radio Call: KA0YKO Email Address: billz@inlink.com Home Page Address: www.inlink.com/~billz ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._ From: znmeb@teleport.com () Subject: Re: Multi-exit loop (Was: Is using mult Exits bad pgrming) Date: 30 Jul 1996 16:57:08 GMT Message-ID: <4tlet4$1ci@nadine.teleport.com> References: <4r2c5p$o89@hkusuc.hku.hk> <4r2jqi$km3@newsbf02.news.aol.com> <4sjevm$187@zeus.tcp.co.uk> <31EF9C3D.2B6F@inlink.com> <4so93r$ddp@dfw-ixnews6.ix.netcom.com> <4tl9im$5a8@news.tuwien.ac.at> Anton Ertl (anton@a0.complang.tuwien.ac.at) wrote: : Of course, I would hide the low-level control-structure words behind : new high-level words, e.g.: : START : ... IF : ... LEAVE-LOOP : ... IF : ... LEAVE-LOOP : ... IF : ... LEAVE-LOOP : ... : END : These words are defined like this: : variable count-leaves : : START ( -- n dest ) : count-leaves @ 0 count-leaves ! POSTPONE begin ; immediate : : LEAVE-LOOP ( dest orig1 -- orig2 dest ) : 1 count-leaves +! POSTPONE ahead 1 cs-roll POSTPONE then 1 cs-roll ; immediate : : END ( n orig1 ... orign dest -- ) : POSTPONE again : count-leaves @ 0 ?DO : POSTPONE then : LOOP : count-leaves ! ; immediate : - anton : -- : M. Anton Ertl Some things have to be seen to be believed : anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen : http://www.complang.tuwien.ac.at/anton/home.html Have you been peeking inside my HP100LX Palmtop?? :-) I am currently writing up a very similar solution to this problem for submission to Forth Dimensions. With any luck at all, I'll have it done in a day or two. -- znmeb@teleport.com (M. Edward Borasky) http://www.teleport.com/~znmeb What is it about @replace(@string(@log(10000)*@atan(1),9),0,0,@char(112)&@char(105)&@char(61)) that you don't understand? From: Bill Zimmerly Subject: Re: Stack Computer book on-line Date: Tue, 30 Jul 1996 23:56:11 -0500 Message-ID: <31FEE76B.1587@inlink.com> References: <31f61e27.6475492@usenet.interramp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailer: Mozilla 2.01Gold (WinNT; I) CC: billz@inlink.com Luc Lefebvre wrote: > = > In article <31f61e27.6475492@usenet.interramp.com>, koopman@cs.cmu.edu > (Phil Koopman) wrote: > = > "> My stack computer architecture book has recently gone out of print, > "> but I still receive occasional inquiries as to availability. The > "> former publisher, Ellis Horwood Ltd., has graciously returned the > "> copyright ownership to me. So, I have decided to place the book > "> on-line at: > "> http://www.cs.cmu.edu/~koopman/stack_computers/index.html > [.......] > "> Happy reading! > = > indeed! > = > [.......] > = > Hi Phil, > = > What a great Idea, thanks. > = > \ > \ Luc Lefebvre > \ Montr=E9al, Canada For anyone interested in one such book, check out this... http://www.well.com/user/hlr/texts/tftindex.html I for one wish that this trend would continue! :-) - Bill -- = \\\|/// \\ ~ ~ // (/ @ @ /) --------------oOOo-(_)-oOOo--------------------------- William B. Zimmerly (Bill) - Systems Research & Development Manager / Webmaster General American Life Insurance Company, Inc. Amateur Radio Call: KA0YKO Email Address: billz@inlink.com Home Page Address: www.inlink.com/~billz ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._ From: Bill Zimmerly Subject: Re: Is using mult Exits bad pgrming Date: Tue, 30 Jul 1996 23:30:25 -0500 Message-ID: <31FEE161.6674@inlink.com> References: <4r2c5p$o89@hkusuc.hku.hk> <6DbcBKtb7QB@business.forth-ev.de> <4tj4iq$h4k@nadine.teleport.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01Gold (WinNT; I) CC: billz@inlink.com znmeb@teleport.com wrote: > ...[snip] > Correct me if I'm wrong, but doesn't a logic analyzer operate by > sampling the busses and displaying instruction and data addresses? If > so, I'd think it would be possible to write your Forth code in a manner > that catered to this. It's been over 12 years since I've done this kind of programming, but yes, that's (was?) a good way to do it. > I'll take *real* cheap and *real* fast! > znmeb@teleport.com (M. Edward Borasky) http://www.teleport.com/~znmeb > > I support the right to keep and arm bears. Bears are already scary enough, but dislexics interpreting the U.S. Constitution are even more scary. - Bill -- \\\|/// \\ ~ ~ // (/ @ @ /) --------------oOOo-(_)-oOOo--------------------------- William B. Zimmerly (Bill) - Systems Research & Development Manager / Webmaster General American Life Insurance Company, Inc. Amateur Radio Call: KA0YKO Email Address: billz@inlink.com Home Page Address: www.inlink.com/~billz ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._ From: Chris Jakeman Subject: Re: Beginners Help.... Date: Tue, 30 Jul 1996 18:12:09 +0100 Message-ID: References: <10@brady.win-uk.net> <31F92D44.6228@austin.finnigan.com> <13@brady.win-uk.net> X-NNTP-Posting-Host: apvpeter.demon.co.uk MIME-Version: 1.0 In article <13@brady.win-uk.net>, Stuart Brady writes > > >>> I have decided to try and learn Forth and I am looking for advice. >>> I LIKE Forth. At the moment I have FPC Forth (v3.56) which seems >>> FPRIMER.ZIP made in 1992(?) >Talking about the lessons brings me to...WHICH BOOK? > >I have dabbled in various programming languages and would describe >myself as having a reasonably good understanding of computers. I >already have a book 'FORTH' by P.A.C. Kail which is a reasonable >introduction[but don't metion proofreading]. I have printed out the >tutorials with FPC. I am looking for a 'middling to advanced' Forth >book. I have seen the recommended texts but I don't know which >would fall into this category. Take a look at the FAQ for Books (Part 5/6) which has 12 titles in the advanced category. It's posted to the newsgroup on the 2nd of each month and kept in ftp://forth.org/pub/forth/FAQ/forthfaq.5 Bye for now _ _______________________| |_____ Chris Jakeman / _Forth_Interest_Group_| |____/ / /_ __ ______ _ _ | | __ at Peterborough / __/ / / / __ / | | | | | |/ / (a cathedral city / / / / / /_/ / | \_| | | < 80 miles north of London) /_/ /_/ /___ / \____| |_|\_\ Where do you come from? / / ______________/ / United Kingdom Voice +44 (0)1733 346477 /_______________/ Chapter From: Bill Zimmerly Subject: Re: WebBook Patent protection Date: Wed, 31 Jul 1996 00:11:10 -0500 Message-ID: <31FEEAEE.7B4E@inlink.com> References: <4s479e$1081@IRIS> <4s5e3o$m6h@newsbf02.news.aol.com> <4tincb$8if@mksrv1.dseg.ti.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01Gold (WinNT; I) CC: billz@inlink.com john r strohm wrote: > > TheWebBook (thewebbook@aol.com) wrote: > : In article <4s479e$1081@IRIS>, William H. Stewart > : writes: > > : >I wonder if your taugh a class in Forth in Dallas around 1983 -- If you > : did I > : >was one of those who had the > : >chance to understand what it was all about. For this I truly thank you! > > : Bill, > > : Blush. Yes, that was me. I rejoined EDS in 1985 and moved to the Detroit > : area and didn't have much of a chance to think about Forth until last > : year. > > I remember a presentation to the Dallas FIG chapter, I think it was yours, > in which a pointer named "ROVER" was walking over a data structure of > some sort. At one point, there was a line in the code where ROVER was > moved off of the current object. When the lecturer was asked about it, > the comment was "Yes, ROVER has teeth!" > > The whole room died laughing at that point. > > Was that you? > > --John Gosh what a small world this is!!!! I was an EDS programmer in St. Louis then...using my custom Z-80 Forth (I called it "Thread") to test circuit boards. I'll never forget the day that I turned in my two weeks notice... ...our boss called everyone into a meeting room to tell us all two things... 1. That we had a psychic among us. (me!) ...and... 2. That GM just bought EDS and everyone else prepare to sell our homes and move to Detroit! - Bill -- \\\|/// \\ ~ ~ // (/ @ @ /) --------------oOOo-(_)-oOOo--------------------------- William B. Zimmerly (Bill) - Systems Research & Development Manager / Webmaster General American Life Insurance Company, Inc. Amateur Radio Call: KA0YKO Email Address: billz@inlink.com Home Page Address: www.inlink.com/~billz ~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._ From: ehp@ear.co.at (Ewald Pfau) Subject: Multi-exit loop (Was: Is using mult Exits bad pgrming) Message-ID: <838794145.AA00411@ear.co.at> Date: Wed, 31 Jul 1996 09:17:42 +0100 X-FTN-To: Ewald Pfau Since it may not seem obvious, for the following: > BEGIN > . WHILE > . . WHILE > . . . WHILE > UNTIL . . > . . . THEN > . . THEN > . THEN let me add, that each THEN may be replaced by the pair ELSE .. THEN. BEGIN . WHILE . . WHILE . . . WHILE UNTIL . . . . . ELSE . . . THEN . . ELSE . . THEN . ELSE . THEN Ewald From: "Elizabeth D.Rather" Subject: Re: multiple entries Date: Wed, 31 Jul 1996 00:20:29 -0700 Message-ID: <31FF093D.3176@earthlink.net> References: <4te5j4$opk@navajo.gate.net> <4tla41$pan@sjx-ixn6.ix.netcom.com> X-NNTP-Posting-Host: forthinc.demon.co.uk X-Mailer: Mozilla 2.01 (Win95; I) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Jonah Thomas wrote: [re maintainability of the code that branches using IF across into a following definition] > One approach to writing maintainable code is to write stupid code. Make > sure everything is clear and obvious. I believe the most maintainable code is not stupid, but brilliantly concise. This isn't the same as obscurely cryptic; it reflects the kind of insight that penetrates to the heart of the problem and yields a clear, simple solution. Kind of like Hemingway prose. "Stupid code" requires slogging through too much laborious & often unnecessary detail, and runs slow besides! > > : GET-PRICE-FIELD-FROM-ITEM#-FIELD ( addr1 -- addr2 ) CELL+ ; > : GET-PRICE-FROM-PRICE-FIELD ( addr -- price ) @ ; >This is _extremely_ obscure to a Forth programmer, who knows exactly what CELL+ and @ do and haven't a clue about these long tedious names. You should write for competant (not necessarily expert) Forth programmers. > Trying to write maintainable code leads to code which is pedestrian. A > long "clear" routine might seem more maintainable than a clever short one. > A mediocre algorithm may be more obvious than a more efficient one. The > dead hand of tradition. I will always vote for efficient code, clearly written and well-documented. It is absolutely not necessary for efficient code to be obscure! > Anyway, maintenance is an unsolved problem, and Forth techniques don't give > us any help with it. Forth gives you as much help as any language. The main requirement (in any language) is programmer discipline. > If Chuck Moore had wanted his code to be maintainable > he'd have written it in Fortran. But then, if he hadn't found a smart > person to do documentation and cleanup for him, his code would have been > unmaintainable. Having maintained both Fortran and Chuck's code (both for a good many years) I prefer Chuck's code any day. -- =============================================== Elizabeth D. Rather 1-800-55-FORTH FORTH Inc. 310-372-8493 111 N. Sepulveda Blvd. Fax: 310-318-7130 Manhattan Beach, CA 90266 http://websites.earthlink.net/~forth "Forth-based products and Services for real-time applications since 1973." =============================================== From: jverne@acs.ryerson.ca (John Verne - CNED/F94) Subject: Re: Stack Computer book on-line Date: 31 Jul 1996 01:10:48 GMT Message-ID: <4tmbqo$aih@ns2.ryerson.ca> References: Julian V. Noble (jvn@faraday.clas.Virginia.EDU) said: : jvn@faraday.clas.Virginia.EDU writes: : [ remarks re: return of copyright deleted ] : > Thanks to Phil Koopman for putting his book on line. However, : > as Cliff Stoll notes in "Silicon Snake Oil", on-line documents : > are not as useful as hard copy ones. : My reference to "Silicon Snake Oil" apparently touched a nerve. : I haven't received so many flames since the time I died and went : to Hell. (in a handbasket, of course :-) : To avoid being classified as a Luddite (look it up if you didn't : pay attention in History 101) of the Web, let me amplify the : above remark. In the following, "book" refers to ink on paper : pages sewn or glued together in sequence. Sorry. Here's my 2 cents: There are a lot of benefits to "soft" documentation. My favourite one is that it can be printed onto paper. All the new tech notwithstanding, I simply don't understand as well, unless I read from a page. A left-over from my early days as a "book-reader", no doubt. I think software marketers know this: most "big" pieces of software come with at least 5kgs of _printed_, _bound_, manuals. Except for microsoft. They expect you to buy the manual, seperately, from their "microsoft press" branch. Am I being unfair to microsoft? Check out any of their "home" products. The docs are a joke. The funniest part is the blurb where they introduce the books that "help" you get the "most" from your new software. 'Nuff said. Jon D. Verne From: JEThomas@ix.netcom.com (Jonah Thomas) Subject: Re: multiple entries Date: 31 Jul 1996 09:55:16 GMT Message-ID: <4tnai4$87j@dfw-ixnews10.ix.netcom.com> References: <4te5j4$opk@navajo.gate.net> <4tla41$pan@sjx-ixn6.ix.netcom.com> <31FF093D.3176@earthlink.net> X-NETCOM-Date: Wed Jul 31 4:55:16 AM CDT 1996 In <31FF093D.3176@earthlink.net> "Elizabeth D.Rather" writes: >Jonah Thomas wrote: >[re maintainability of the code that branches using IF across into a >following definition] >> One approach to writing maintainable code is to write stupid code. Make >> sure everything is clear and obvious. >I believe the most maintainable code is not stupid, but brilliantly >concise. This isn't the same as obscurely cryptic; it reflects the kind of >insight that penetrates to the heart of the problem and yields a clear, >simple solution. Kind of like Hemingway prose. "Stupid code" requires >slogging through too much laborious & often unnecessary detail, and runs >slow besides! Agreed. And you know brilliantly concise code when you see it. But I might think I know it when I see it, and be wrong. It looks like an art. >> : GET-PRICE-FIELD-FROM-ITEM#-FIELD ( addr1 -- addr2 ) CELL+ ; >> : GET-PRICE-FROM-PRICE-FIELD ( addr -- price ) @ ; >This is _extremely_ obscure to a Forth programmer, who knows exactly what >CELL+ and @ do and haven't a clue about these long tedious names. Yes. Although the tedious names might be useful at some level, they say what is being done, rather than how. But at too low a level of abstraction. Getting it right looks like more artwork to me, at this point. >You should write for competant (not necessarily expert) Forth programmers. That sounds good, and sensible. >> Trying to write maintainable code leads to code which is pedestrian. A >> long "clear" routine might seem more maintainable than a clever short one. >> A mediocre algorithm may be more obvious than a more efficient one. The >> dead hand of tradition. >I will always vote for efficient code, clearly written and well-documented. >It is absolutely not necessary for efficient code to be obscure! Again good, and thank you. Once again, though, there's an extra level of artistry to writing efficient code that's also clearly written. >> Anyway, maintenance is an unsolved problem, and Forth techniques don't give >> us any help with it. >Forth gives you as much help as any language. The main requirement (in any >language) is programmer discipline. Yes. My point is that Forth doesn't give us _more_ help than other languages for this problem. Forth offers solid advantages for communicating with the machine. It doesn't give us extra help for communicating with each other about what we told the machine. We can quickly interact with the machine and see what it thinks is happening. We can't so quickly interact with each other, and Forth doesn't help us do that faster. When I read someone else's code, I like to have my compiler handy. Incrementally compile as I read. Test pieces and _see_ what they do. Sometimes that helps me over the rough spots more than any amount of documentation. But it's still slow when there are rough spots that deserve such effort. I'm not sure what Forth tools would help me read code faster and more efficiently. But Forth is so good at showing me what the machine thinks _my_ code means, there ought to be some good way to get it to explain to me what somebody else's code means. From: Paul Shirley Subject: Re: multiple entries Date: Mon, 29 Jul 1996 23:35:36 +0100 Message-ID: References: <4tco6m$mf9@hkusuc.hku.hk> <4tf0ud$ani@news.third-wave.com> Mime-Version: 1.0 >Zsoter Andras (h9290246@hkuxa.hku.hk) wrote: >: Now, I would be curious to see what multiple entry points are useful >: for. 1: Presetting common or default parameters My Genesis game library *shrank* from 20K lines to 15 over 2 years by ruthless application of this, yet gained more functionality. Something like DrawSprite16x16 moveq #16,d2 moveq #16,d3 DrawSprite {...} 2: Re-entering complex looping routines with simplified setup. This has provided noticeable speedups in some of my graphics pipelines AND reduced the size of the code. Basically, its an size and speed optimising technique, although it has a potential benefit in only having one copy of a routine to maintain rather than several. -- Paul Shirley From: znmeb@teleport.com () Subject: Re: Is using mult Exits bad pgrming Date: 31 Jul 1996 15:04:59 GMT Message-ID: <4tnsmr$7n3@nadine.teleport.com> References: <6DS5A4LGCHB@malente.forth-ev.de> <4t8sfd$cg4@nadine.teleport.com> <31FEE2D7.7785@inlink.com> Bill Zimmerly (billz@inlink.com) wrote: : znmeb@teleport.com wrote: : > ...[snip] : > ... : > 2. I rather like the Edsger Dijkstra guarded command syntax as developed : > in "A Discipline of Programming". Now *there's* a book that's crying : > out to be translated into Forth! I'm sure by now someone has : > translated his *two* control structures into Forth -- I didn't see it : > in my indexes of Forth Dimensions or FORML proceedings, though. If : > no one has done it, I might be persuaded to use the ANS : > "roll-your-own-control-structure" words (CS-ROLL, CS-PICK, AHEAD) to : > do a sequentrial implementation without Dijkstra's non-deterministic : > semantics. : Excellent suggestion! : - Bill I spent a few hours on it, and decided to write it up as an article for Forth Dimensions, since they are looking for articles on practical experience with ANS Forth. After seeing the discussion on various mixed-up and unreadable loops composed of the given ANS control flow words, I'm really glad I coded them. -- znmeb@teleport.com (M. Edward Borasky) http://www.teleport.com/~znmeb Actually, for their size, elephants don't smell all that bad. "The only thing we have to fear is fear itself -- and, of course, the boogeyman." Pat Paulsen From: znmeb@teleport.com () Subject: Re: Is using mult Exits bad pgrming Date: 31 Jul 1996 15:15:56 GMT Message-ID: <4tntbc$881@nadine.teleport.com> References: <4r2c5p$o89@hkusuc.hku.hk> <6DbcBKtb7QB@business.forth-ev.de> <4tj4iq$h4k@nadine.teleport.com> <31FEE161.6674@inlink.com> Bill Zimmerly (billz@inlink.com) wrote: : Bears are already scary enough, but dislexics interpreting : the U.S. Constitution are even more scary. Well, then you'll be interested in my view on gnu control. My motto is, "No gnus is good news!". -- znmeb@teleport.com (M. Edward Borasky) http://www.teleport.com/~znmeb Give me your brains or I'll blow your money out. From: "Paul E. Bennett" Subject: Re: Is using mult Exits bad pgrming Date: Wed, 31 Jul 96 15:56:21 GMT Message-ID: <838828581snz@tcontec.demon.co.uk> References: <4r2c5p$o89@hkusuc.hku.hk> <6DbcBKtb7QB@business.forth-ev.de> <4tj4iq$h4k@nadine.teleport.com> <4tkmpa$3gf@majipoor.cygnus.com> Reply-To: peb@transcontech.co.uk X-NNTP-Posting-Host: tcontec.demon.co.uk X-Mail2News-Path: tcontec.demon.co.uk In article <4tkmpa$3gf@majipoor.cygnus.com> aph@phal.cygnus.co.uk "Andrew Haley" writes: > znmeb@teleport.com wrote: > : Wolfgang Allinger (All@business.forth-ev.de) wrote: > : : In forth words I use a lot of 'IF ... EXIT THEN' in the beginning to > : : handle the special cases. A logic analyser is nearly useless in forth, so > : : I do what it makes it easier for me. > > : Correct me if I'm wrong, but doesn't a logic analyzer operate by > : sampling the busses and displaying instruction and data addresses? If > : so, I'd think it would be possible to write your Forth code in a manner > : that catered to this. > > That's not really the point. If you use Forth to develop embedded > applications, a logic analyzer is redundant: you use interactivity > instead of staring at traces. Interactivity is cheaper and more > productive. > Actually Andrew, you should have said a logic analyser is "mostly" redundant when using Forth for development. There may be some very rare case where the use of one will be necessary. However, these occassions will be so rare that it is not worth owning an analyser of ones own. -- Paul E. Bennett Transport Control Technology Ltd. Tel: +44 (0)117-9499861 Going Forth Safely From: elvey@civic.hal.COM (Dwight Elvey) Subject: Re: Manipulating Return Addresses Date: 31 Jul 1996 20:06:29 GMT Message-ID: <4toec5$6ih@bastion4.hal.com> References: <31F76F75.5E13@headwaters.com> In article , Chris Jakeman writes: |> In article , "W.Baden" |> writes |> >Applications that need Return Stack Manipulations would be better |> >written in another language. E.g. there are regular expression |> >packages more powerful and more efficient than anything written in |> >Forth that can be had for the downloading. |> |> There's a challenge! I have no evidence yet that pattern-matching in |> Forth is more efficient than in conventional languages, but it is |> certainly different. Given a small set of operators for manipulating |> Return Addresses, Gordon Charlton's FOSM will compile a pattern and |> execute it. Conventional languages have to store that pattern as a |> state machine and interpret that. Sounds less efficient to me ... |> |> Perhaps Michael Gassanenko can tell us how BacForth compares in power |> and efficiency? |> |> Bye for now _ |> _______________________| |_____ |> Chris Jakeman / _Forth_Interest_Group_| |____/ |> / /_ __ ______ _ _ | | __ |> at Peterborough / __/ / / / __ / | | | | | |/ / |> (a cathedral city / / / / / /_/ / | \_| | | < |> 80 miles north of London) /_/ /_/ /___ / \____| |_|\_\ |> Where do you come from? / / |> ______________/ / United Kingdom |> Voice +44 (0)1733 346477 /_______________/ Chapter Hi Chris I think he meant assembly. I can't think of a compiled language other than Forth that would even think of letting me put some defered action on the return stack. Sorry Wil, I don't mean to put words in your mouth, it's just that I don't know how using another language will solve the problems I solved by using the return stack addresses. Dwight From: frank@bigdog.engr.arizona.edu (Frank Manning) Subject: Re: Stack Computer book on-line Date: 31 Jul 1996 20:13:16 GMT Message-ID: <4toeos$ti8@news.ccit.arizona.edu> References: <9607290836.aa25120@deepthought.armory.com> In article <9607290836.aa25120@deepthought.armory.com> rstevew@armory.com (Richard Steven Walz) writes: > [...] > And if you trusted valued programs to punch-tape and didn't keep your > own punch-tape reader [...] Even if you can't find a paper tape reader, the optical, electronic and computer hardware available even to hobbyists is so good today I bet you could make your OWN paper tape reader. A hand-scanner or QuickCam and some trivial image processing software, along with some sort of tape winder and indexing mechanism would probably do the job. I bet Steve could put one together in a couple of days, even less if you don't include the time he spends pounding on shriek keys!!!! -- Frank Manning From: linkcom@bastian.moldenett.no Subject: Re: Looking for better names for array operations Date: 31 Jul 1996 14:44:02 GMT Message-ID: <4tnrfi$d7g@nic.global-one.no> References: <4tk3l0$1524@news.goodnet.com> Reply-To: linkcom@bastian.moldenett.no In <4tk3l0$1524@news.goodnet.com>, Brad Eckert writes: > >I use often use COUNT for something other than what it's name implies. >For example: > >: type 0 ?do count emit loop drop ; > >In this case, COUNT should probably go by another name. >I've been thinking of UNLAY, since it deals with strings. LAY and UNLAY >seem like pretty useful primitives. > >Sample usage: > >: unlay ( a -- a+1 c ) count ; >: lay ( a c -- a+1 ) over c! 1+ ; > >: type ( a n -- ) > 0 ?do unlay emit > loop drop ; > >: cmove ( asrc adest n -- ) > 0 ?do swap unlay > swap lay > loop 2drop ; > >-LAY and -UNLAY could be similar except index backwards. I don't >know what to call versions that would deal with cell-size data. > >Any suggestions for names? > >-- Brad > > > We call these functions "c@++", "c!++", "--c@" and "--c!". Versions for cell sized data is called: "@++", "!++", "--@" and "--!". We even have a string version called "s!++". I have no idea where this notation came from :-) : c@++ ( a -- a+1 c ) dup 1+ swap c@ ; : count ( a -- a+1 c ) c@++ ; : c!++ ( a c -- a+1 ) over c! 1+ ; : --c@ ( a -- a-1 c ) 1- dup c@ ; : --c! ( a c -- a-1 ) swap 1- tuck c! ; : @++ ( a -- a+1 c ) dup cell+ swap @ ; : !++ ( a c -- a+1 ) over ! cell+ ; : --@ ( a -- a-1 c ) cell- dup @ ; : --! ( a c -- a-1 ) swap cell- tuck c! ; : s!++ ( a1 a2 l2 -- a1+l2 ) \ copy l2 bytes from a2 to a1 and leave a1+l2 on the stack 0 do c@++ rot swap c!++ swap loop drop ; Regards Pal Nyland --- Pal Nyland Linkcom Business Development AS P.O. 197 N-6401 Molde Phone: +47 71215744 Fax: +47 71215717 Email: linkcom@moldenett.no From: Paul Shirley Subject: Re: multiple entries Date: Wed, 31 Jul 1996 19:09:12 +0100 Message-ID: References: <4tco6m$mf9@hkusuc.hku.hk> <4tf0ud$ani@news.third-wave.com> Mime-Version: 1.0 >Zsoter Andras (h9290246@hkuxa.hku.hk) wrote: >: Now, I would be curious to see what multiple entry points are useful >: for. 1: Presetting common or default parameters My Genesis game library *shrank* from 20K lines to 15 over 2 years by ruthless application of this, yet gained more functionality. Something like DrawSprite16x16 moveq #16,d2 moveq #16,d3 DrawSprite {...} 2: Re-entering complex looping routines with simplified setup. This has provided noticeable speedups in some of my graphics pipelines AND reduced the size of the code. Basically, its an size and speed optimising technique, although it has a potential benefit in only having one copy of a routine to maintain rather than several. -- Paul Shirley Date: 31 Jul 1996 10:52:00 +0100 From: All@business.forth-ev.de (Wolfgang Allinger) Message-ID: <6DvhkkIb7QB@business.forth-ev.de> References: <4r2c5p$o89@hkusuc.hku.hk> <6DbcBKtb7QB@business.forth-ev.de> <4tj4iq$h4k@nadine.teleport.com> Subject: Re: Is using mult Exits bad pgrming On 29 Jul 96 in article <4tj4iq$h4k@nadine.teleport.com> wrote: >Wolfgang Allinger (All@business.forth-ev.de) wrote: snipp--- >: In forth words I use a lot of 'IF ... EXIT THEN' in the beginning >to : handle the special cases. A logic analyser is nearly useless in >forth, so : I do what it makes it easier for me. > >Correct me if I'm wrong, but doesn't a logic analyzer operate by >sampling the busses and displaying instruction and data addresses? Thats exactly the Problem, you trigger/trace on op-codes, you will see always the NEXT, sometimes the NEST routine, if you trigger/trace the Data stream, you cannot see the differences between data and cfa's. Also you usually don't know the cfa's... >If so, I'd think it would be possible to write your Forth code in a >manner that catered to this. I would be very happy, if somebody can show me a way! >: -- >: FORTHing @ work Cheap >: Fast Good ...pick any two of them >I'll take *real* cheap and *real* fast! Fine! >I support the right to keep and arm bears. That's even better! Bye by Wolfgang -- FORTHing @ work Cheap Fast Good ...pick any two of them Dipl.-Ing. Wolfgang Allinger Brander Weg 6 Voice/FAX [+49] [0] 212 / 66 8 11 D-42699 SOLINGEN eMail: all@business.forth-ev.de GERMANY ## CrossPoint v3.1 R ## From: Stephen Pelc Subject: Re: Multi-exit loop (Was: Is using mult Exits bad pgrming) Date: Wed, 31 Jul 96 22:30:43 GMT Message-ID: <838852243snz@mpeltd.demon.co.uk> References: <4r2c5p$o89@hkusuc.hku.hk> <4r2jqi$km3@newsbf02.news.aol.com> <4sjevm$187@zeus.tcp.co.uk> <31EF9C3D.2B6F@inlink.com> <4so93r$ddp@dfw-ixnews6.ix.netcom.com> <4tl9im$5a8@news.tuwien.ac.at> Reply-To: sfp@mpeltd.demon.co.uk X-NNTP-Posting-Host: mpeltd.demon.co.uk X-Mail2News-Path: mpeltd.demon.co.uk > In article <4so93r$ddp@dfw-ixnews6.ix.netcom.com>, JEThomas@ix.netcom.com > (Jonah Thomas) writes: > |> ... BEGIN ... WHILE ... WHILE ... WHILE ... REPEAT ... ELSE ... THEN ELSE > ... > |> THEN ; May I take this opportunity to offer a construct which a) takes advantage of words in common use b) only requires one extra Forth word The problem is to associate the multiple loop exit actions with the exit conditions. The exampl above and its ilk do no achieve this (IMHO). Compare this with the currently common CASE ... ENDCASE structure CASE OF ENDOF OF ENDOF OF ENDOF ... ENDCASE We can turn this into loop with the following simple change CASE OF ENDOF OF ENDOF OF ENDOF ... NEXTCASE where NEXTCASE generates a branch to just after the CASE. Note that the ENDOFs can still generate the same code as before, so exiting the loop and continuing just after the NEXTCASE. -- Stephen Pelc, sfp@mpeltd.demon.co.uk MicroProcessor Engineering - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 1703 631441, fax: +44 1703 339691 From: aph@phal.cygnus.co.uk (Andrew Haley) Subject: Re: Manipulating Return Addresses Date: 1 Aug 1996 10:27:22 GMT Message-ID: <4tq0qa$mho@majipoor.cygnus.com> References: <31F76F75.5E13@headwaters.com> <4toec5$6ih@bastion4.hal.com> Dwight Elvey (elvey@civic.hal.COM) wrote: : I can't think of a compiled : language other than Forth that would even think of letting : me put some defered action on the return stack. A language which supports continuations will allow this. I believe that common LISP, which is often compiled, supports continuations. Andrew. From: mikc@gnu.ai.mit.edu (Mike Coughlin) Subject: Re: Stack Computer book on-line Date: 1 Aug 1996 14:08:50 GMT Message-ID: <4tqdpi$2q5@life.ai.mit.edu> References: <4ths82$6mt@murrow.corp.sgi.com> <31FCC0F7.488B@informatik.tu-muenchen.de> In article , Tim Bradshaw wrote: :* Bernd Paysan wrote: :> Steve Alexander wrote: :>> Also, I believe that I read a few years back that a lot of the raw data :>> collected in the 50s and 60s is now useless since the tape formats :>> (probably 80-column card images) can't be interpreted without the :>> original computer programs. Don't quote me on this, I can't remember :>> the source... :> It's more likely that the information on the tape is completely :> gone. I can't imagine any higher level of cryptography applied to :> these tapes (Read Solomon would be difficult enough), so even if the :> character set, the bit size and the format is unknown, it can be :> easily retrieved using some cryptanalytic methods. :Yes but what you end up with is something like a string of decimal :numbers which once meant something to someone but no one can remember :what it was and what was which. And unless you know lots of details :of the equipment they came from and the program that used them, you :have a very hard problem. Somewhere there exists documentation on paper with all this information. It even likely to be archived so future historians will be able to dig it up. Of course it would be such a time consuming task to find everything needed that such information would not be of much practical use when somebody wanted to read old data today. -- Michael Coughlin mikc@gnu.ai.mit.edu Cambridge, MA USA From: ehp@ear.co.at (Ewald Pfau) Subject: Multi-exit loop (Was: Is using mult Exits bad pgrming) Message-ID: <838890489.AA00413@ear.co.at> Date: Thu, 01 Aug 1996 12:02:56 +0100 X-FTN-To: Stephen Pelc [..] SP> We can turn this into loop with the following simple change SP> CASE SP> OF ENDOF SP> OF ENDOF SP> OF ENDOF SP> ... SP> NEXTCASE SP> where NEXTCASE generates a branch to just after the CASE. Note that SP> the ENDOFs can still generate the same code as before, so exiting SP> the loop and continuing just after the NEXTCASE. This suggests either, not to use the C-stack for resolving forward branches or to have an extra C-stack for resolving backwards branches. How can otherwise the backwards branch be compiled, if the C-stack holds the references for the implicit THENs? OF compares two numbers to be equal. This is different from consuming a flag. So it would be 'number1..' above instead of 'condition1..'. Or but you have a special idea about OF..ENDOF? It remained numbers even if we had SAME-OF, GREATER-OF, RANGE-OF... Maybe, 'near' ELSEs (as compiled by ENDOF) are easier to be memorized than 'far' ELSEs. For execution flow, both are the same. It is a conditional branch and an unconditional branch (the logical path differs). The latter ones, 'far' ELSEs, may be compiled by what is given in ANS without an explicit CS-ROLL. The difference is, to introduce an alternate path together with the conditional to which it is an alternative, for 'near'. You think of it as having had an IF and replace it by IF..ELSE. For 'far', the alternate path is introduced when resolving the THENs. You think of it as having had THEN and replace it by ELSE..THEN. By the latter one, you have to memorize, to which IF a THEN belongs to. By use of a proper graphical layout, this may be as well easy. For the 'near' ELSEs, Wil Baden showed his use of BUT. As I learnt meanwhile, he was the one who once introduced the SO and STILL, which were replaced by the more technical terms CS-PICK and CS-ROLL for ANS Forth then. 'near': BEGIN . IF end-01 . ELSE loop-01 [ 1 CS-ROLL ] . IF end-02 . ELSE loop-02 [ 1 CS-ROLL ] AGAIN . THEN . THEN This results either from 'FLAG-OF .. ENDOF [ 1 CS-ROLL ]' or from 'IF .. ELSE BUT'. 'far': BEGIN . WHILE loop-01 . WHILE loop-02 AGAIN . ELSE end-02 . THEN . ELSE end-01 . THEN WHILE is 'IF [ 1 CS-ROLL ]'. Ewald From: Blue Line Engineering Company Subject: multi-tasking & serial I/O Date: Thu, 01 Aug 1996 14:10:16 -0600 Message-ID: <32010F28.587D@rmi.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 2.01 (Win95; I) I am working on a Vesta 68332 board using FORTH. In my implementation, I would like to use multitasking, with one task dedicated to handling RS232 communications to a PC. I've run into a few problems with not detecting incoming characters from the PC (using KEY and KEY?) when my serial comm task is not running. Shouldn't KEY? "remember" that a character has arrived, even if it arrived when another unrelated task was executing? It appears that when my serial comm task gets its turn to run, the incoming character has been lost. Anyone have experience with this problem, or perhaps does anyone know of a code sample that I could examine to see how I might alter my design? Steve Bygren From: Bernd Paysan Subject: Re: Multi-exit loop (Was: Is using mult Exits bad pgrming) Date: Thu, 01 Aug 1996 00:34:43 +0200 Message-ID: <31FFDF83.37939259@informatik.tu-muenchen.de> References: <4r2c5p$o89@hkusuc.hku.hk> <4r2jqi$km3@newsbf02.news.aol.com> <4sjevm$187@zeus.tcp.co.uk> <31EF9C3D.2B6F@inlink.com> <4so93r$ddp@dfw-ixnews6.ix.netcom.com> <4tl9im$5a8@news.tuwien.ac.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b5 (X11; I; Linux 2.0.10 i486) Anton Ertl wrote: > Of course, I would hide the low-level control-structure words behind > new high-level words, e.g.: > > START > ... IF > ... LEAVE-LOOP > ... IF > ... LEAVE-LOOP > ... IF > ... LEAVE-LOOP > ... > END > > (yes, the names may not be optimal). gforth provides this using BEGIN BEGIN ... ?LEAVE ... ?LEAVE ... ?LEAVE AGAIN DONE so you simply define : START postpone BEGIN postpone BEGIN ; immediate : END postpone AGAIN postpone DONE ; immediate The BUT mentioned by Will Baden is part of gforth, too. The other control flow stack manipulator is YET, which is the equivalent of [ 1 CS-PICK ]. However, neither the BEGIN ... DONE trick (resolve LEAVEs without a DO LOOP around them, found in Dr. Dobb's) nor the BUT/YET cs effects are described in the gforth manual, so Anton is excused for not knowing this... -- Bernd Paysan "Late answers are wrong answers!" http://www.informatik.tu-muenchen.de/~paysan/ From: znmeb@teleport.com () Subject: Automated Nuclear Support Date: 1 Aug 1996 15:49:07 GMT Message-ID: <4tqjlj$k7g@nadine.teleport.com> [ Article crossposted from rec.humor.funny ] [ Author was BRENT J FINLEY ] [ Posted on Thu, 1 Aug 96 4:30:06 EDT ] Last week we were having a weekly teleconference call with our NSSS vendor (they built our nuclear reactor at Palo Verde generating station.) We kept getting a voice mail and someone commented that they didn't have a secretary so it would be useless to press "0" to try to get a real live person. We then thought they should try an automated menu system for their office. It might sound something like this... "If you need assitance responding to an NRC fine or violation...please press '1'... If your reactor is on fire...please press '2'... If your reactor has melted...please press '3'... From: Stephen Pelc Subject: Re: Multi-exit loop (Was: Is using mult Exits bad pgrming) Date: Thu, 01 Aug 96 22:06:45 GMT Message-ID: <838937205snz@mpeltd.demon.co.uk> References: <838890489.AA00413@ear.co.at> Reply-To: sfp@mpeltd.demon.co.uk X-NNTP-Posting-Host: mpeltd.demon.co.uk X-Mail2News-Path: mpeltd.demon.co.uk In article <838890489.AA00413@ear.co.at> ehp@ear.co.at "Ewald Pfau" writes: > SP> We can turn this into loop with the following simple change > SP> CASE > SP> OF ENDOF > SP> OF ENDOF > SP> OF ENDOF > SP> ... > SP> NEXTCASE > SP> where NEXTCASE generates a branch to just after the CASE. Note that > SP> the ENDOFs can still generate the same code as before, so exiting > SP> the loop and continuing just after the NEXTCASE. > This suggests either, not to use the C-stack for resolving forward branches or > to have an extra C-stack for resolving backwards branches. How can otherwise > the backwards branch be compiled, if the C-stack holds the references for the > implicit THENs? For a traditional style of implementation, just reserve space for the branch compilation, resolve the THENS, and then fill in the branch values. > OF compares two numbers to be equal. This is different from consuming a flag. > So it would be 'number1..' above instead of 'condition1..'. Or but you have a > special idea about OF..ENDOF? The Forth literature includes several modifications to the basic OF ... ENDOF phrase. The most popular seems to be ?OF which takes a flag and behaves like IF. Please note that I am proposing this notation because it is visually clean, keeps the code next to the code, and thus leads to more obvious and more maintainable code. -- Stephen Pelc, sfp@mpeltd.demon.co.uk MicroProcessor Engineering - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 1703 631441, fax: +44 1703 339691