Subject: ANS Forth. HEELP! From: Victor V. Sovetov Date: Thu, 02 Feb 95 15:13:42 +0200 Reply-To: victor@comcon.kiev.ua X-Mailer: rnMac v1.3b6 Hi, All! Please, tell me address of ftp site conyains ANS Forth specification. Thanks! --victor From: sfp@mpeltd.demon.co.uk (Stephen Pelc) Subject: Re: Summary: large physical memory access on a PC Reply-To: sfp@mpeltd.demon.co.uk X-Posting-Host: mpeltd.demon.co.uk Date: Thu, 2 Feb 1995 18:05:47 +0000 In article rhh@lht.rwth-aachen.de "Robert Hoeller" writes: > I was reminded that there are at least 3 (4) commercial Forth packages > doing exactly what I was looking for: > > UrForth/386 LMI > PolyForth/386 Forth Inc. > iForth Marcel Hendrix > ????? MPE The MPE product is called ProForth for DOS, and is compatible with ProForth for Windows. -- 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: rdr@sydney.DIALix.oz.au (Richard de Rozario) Subject: doubly linked list in 1 field Date: 3 Feb 1995 07:51:05 +1100 NNTP-Posting-User: rdr Here's a little curio: a doubly linked list using a single link field. It hinges on the fact that if you XOR two values together, then given the result and one of the original values XOR will produce the other original value. For example, 1 XOR 2 will produce 3 and 3 XOR 1 will produce 2. This technique is also used in some encryption techniques. To create a doubly linked list we store the XOR of the predecessor and the successor in the link field. The first and last items in the list have a predecessor and successor of some special value (like zero) that we can recognise as the end of the list. An example of the list link fields for three elements: Address Contents A [ 0 xor B ] B [ A xor C ] C [ B xor 0 ] To process the list we need two addresses: the predecessor and the current element. So, to process our example list from the start, we would need 0 and A. Then to get the next element we read the contents of A and XOR it with the predecessor 0. This would result in B. Then we repeat the operation with the address pair A and B. When we reach the pair C and 0, we know we've reached the end of the list (of course, we could just swap the order of the pair to 0,C and keep going in the reverse direction). To insert an element in the list, we just need to be careful to about using the correct XOR values. Here's an example of linking an element H into our example list: Address Contents Change to A [ 0 xor B ] [ 0 xor H ] B [ A xor C ] [ H xor C ] C [ B xor 0 ] H [ ] [ A xor B ] Below is the code (in Pygmy Forth) for creating lists of strings. LNEXT is the word that calculates the next link pair. LINSERT grab the next dictionary space and use it as a new link field (linked in between the current address pair on the stack). In other words, it does what the above example shows (where H is the simply the next dictionary space). By linking in the next dictionary space, we can then for example compile a string into the dictionary after that -- effectively creating a link&data combination. This is what the word ^" does. The word NUL always puts the address of nul on the stack. The variable nul is only important for its address, because that's the address that indicates we've reached the end of the list. To create a new list we start of with nul,nul on the stack and then successively insert elements. BTW, the word LINSERT is a good case for the use of local variables -- it gets pretty messy using SWAPs, DUPs and TUCKs. For those of you that may not have seen my posting on local variables for Pygmy, ~ B initialises variable B with a value from the stack and it is a variable that automatically retrieves it's value. The example compiles a list of three strings and then processes the list in both directions. Have fun with it. _--_|~\ Sydney 3JAN95 / \ ( *) RdR \_.--. / \/ PS. I don't remember where I first came across this technique, but I do remember they didn't list credits for it. So, "Skoal!" to whoever invented it. VAR: A VAR: B : LNEXT ( ab--bc) TUCK @ XOR ; : LINSERT ~ B ~ A ( ab--ah) A @ B XOR HERE XOR A ! B @ A XOR HERE XOR B ! A HERE A B XOR , ; VARIABLE nul VAR: NUL nul TO NUL : ^" ( ab--ah) LINSERT 34 WORD C@ 1+ ALLOT ; : DOCELL ( a--) 2+ TYPE$ ; : DOLIST ( ab--an) BEGIN DUP NUL = 0= WHILE DUP DOCELL LNEXT REPEAT ; ( Example) VAR: TLIST HERE TO TLIST ( tlist points to start of new list) NUL NUL ^" Hello " ^" World " ^" That's all " DROP DROP NUL TLIST DOLIST CR SWAP DOLIST From: snf_dw@debet.nhh.no Subject: Re: Looking for FORTH references... Date: 2 Feb 95 16:18:24 MET In article <3gbg0r$lv@newsbf02.news.aol.com>, erather@aol.com (Erather) writes: > snf_dw@debet.nhh.no (David Walker) writes: > >>Your mention of teaching IBM about Open Firmware should lead you to >>ask yourself, was it just engineering excellence that motivated IBM >>to want this ? > > Your question (and the rest of your discussion) is very appropriate, and I > entirely agree with your point that the "legitimacy" issue is the greatest > impediment to Forth's growth. Although you express it somewhat > differently, this is the point I have been trying to stress for years, > whenever folks here or wherever start claiming that "if only someone write > a really good PD Forth folks would see how good it is", or "if only folks > would stop advocating blocks the world would accept Forth" etc. > ... > > When selling (in person, in sales lit, in articles, etc.) I drop names of > well-known and respected Forth users whenever possible. It's not uncommon > for a prospective user to ask us for (and get) references. It then > becomes essential for our customers to be willing and able to tell others > that they have gotten good results from using our products, that we have > supported them well, etc. I'm not talking about the intrinsic beauty, > efficiency, etc. of code, but the success of the project. That _is_ > something that prospective users look at and care about. > These are good, classical points, I think. Similarly I got some mileage out of the Novix chip being tested to be faster at the Dept of Energy Oak Ridge, than Lilith, the competing Pascal machine. Forth has always benefited from its origins in advanced scientific milieux and this has given it some legitimacy, when we remember to quote and use the fact. But to survive we also have to look forward and participate in the visions of powerful strategists for the future. Power being what it is these go beyond excellence and success. At worst such visions imply conformance with technically faulty and inadequate standards, crippled systems, etc. Everything that Forth lets you escape from. But in the better cases, understanding which strategies are likely to win provides new, legitimate niches in a rapidly changing world, as in Mitch Bradley's work. In such cases, Forth is able to shine and survive in new roles. Whatever you may think of Bill Gates, he is highly qualified as a strategist. In spite of the recent floating point problem and its early handling, Intel still has a uniquely creative strategic point of view. Sun Microsystems and Compaq grew because of an overall vision of where they were going and how there were going to get there, e.g. licensing of Sparc to other suppliers, and Compaq's double edge combining IBM compatibility with full-featured machine portability. These viewpoints were not all compatible with engineering excellence, but in some cases they produced the resources that encouraged and developed it. Bill Gates' strategy was discussed and interviewed extensively in a recent issue of _Fortune_ . In addition to what is said there, many of you know that he was co-writer of the first BIOS and that he insisted on property rights to it and resisted attempts to copy it. Early readers of BYTE will also know the origins of MS-DOS. Fewer of you will know the frequency with which the Gates family name ducks up over the last 100 years or so among billionaire steel magnates, fabulously successful stock market speculators, etc. Somehow Fortune missed the two major points: -- Bill Gates was personally involved in strategically important software development (the BIOS) -- Unless his branch of the Gates family is not as closely related to other very well known Gates's as I imagine it is, Bill Gates is not an entirely self-made man, but the successful protege of one of the most powerful and savvy families in the U.S. I think the purchase and further development of MS-DOS from Seagate in cooperation with IBM should be viewed in that light. I may be wrong on some of these points, or I may be missing something. Generally speaking, Forth enthusiasts tend to be better informed about this sort of thing than the average reader of Fortune. So I ask you to look again at the OpenBoot stuff and think about how it is more than a success story. It is also well positioned. Because of Forth's extreme versatility and rapid approach to new hardware (and I would argue, new software interfaces that should be viewed like new hardware), its strategic potential is enormous. So, where else can Forth be applied in crucial roles that make use of its unique characteristics, in the mainstream of development ? Rgds, David Walker snf_dw@debet.nhh.no From: rdr@sydney.DIALix.oz.au (Richard de Rozario) Subject: Re: doubly linked list in 1 field Date: 8 Feb 1995 06:58:41 +1100 NNTP-Posting-User: rdr I'm glad somebody does (although warnings about lists and pointers are worth keeping in mind -- it's dynamite in more sense than one). BTW, I belatedly changed a ^" to ," and added two more words: : (" NUL NUL \ ," ; ( The word \ in Pygmy = [COMPILE] in f83) : ,) DROP DROP ; and I made all three words immediate. This allows me to do things like this: : test (" hello" ," world" ," that's" ," all" ,) ; Syntactic sugaring maybe, but easier to read I think. RdR From: greg@minerva.com (Greg Bailey) Subject: Re: X3J14 TC Document Posted Date: Tue, 7 Feb 1995 22:49:41 GMT In article <3h8fka$i5i@controversy.math.lsa.umich.edu>, dnw@williams (David N. Williams) says: > [...] >: On the other hand the document is *not* posted so that people can >: just print copies on paper to avoid buying a copy. It is also not >: posted so that some outfit can start printing copies and offering >: them for sale. Either of these uses would, as far as I am aware, >: contravene the TC's intent as stated. > >I sort of took it for granted that one wasn't supposed to copy and sell >it, but actually I see nothing in the statement about not printing copies, >as long as they are complete. I would certainly hope I'm allowed to >print at least a personal copy! Am I mistaken? Depends on why you are doing it. ATHENA owns a copy of the Official document so that we can check for differences in any area that is critical. We could not claim compliance without doing this, since the only Standard is the Official printed version and there may exist differences. If we just printed the working document off for inhouse use and did not buy a copy of the Standard we would have no basis for making compliance statements. Moreover please note that the TC has been advised that it is entitled to make any use of its working documents that it wishes, so long as they are clearly not the official standard. If ANSI does not sell any noticeable number of copies of the Official Standard, I would not be surprised if that policy were changed. Think about it. >: Remember that this is *not* the official document. There are, >: however, countless creative uses that may be made of the *infor- >: mation* in this *working* document which would greatly benefit >: programmers, not to mention making it far more practical to meet >: the documentation requirements imposed by the Official Standard. > >: If you want to be certain that your conduct is consistent with >: the TC's purposes, I would personally recommend that you or >: anyone else retrieving the document plan to do something con- >: structive and original with it. > >: Opinions above are my own. > >One thing that seemed to me a little anomalous was the statement that one >could use it as a foundation for textbooks and system manuals, on the one >hand, but could not reduce its content, on the other. This would seem >to preclude putting only the precisely quoted word specifications in the >appendix of a textbook, for example. > >I'm getting the impression that one of the uses I would like to make of it >would be illegal, namely, to include quoted word specifications for each >word as comments in my source code. Or not?! Julian Noble asked the same question. Since the TC, as far as we have been told, owns the copyright to the working document, I would suggest that you address this question directly to TC chair, Elizabeth Rather (Elizabeth.Rather@minerva.com works) and copy x3j14@minerva.com, for a ruling. From: jhoward@solar.sky.net (John Howard) Subject: Re: X3J14 TC Document Posted Date: 8 Feb 1995 11:15:08 GMT Greg Bailey (greg@minerva.com) wrote: : +-----------------------------------------------+ : | Greetings from the X3J14 Technical Committee. | : | This message has been prepared on 3 Feb 95 | : | by direction of TC Chair. | : +-----------------------------------------------+ : The Technical Committee announces the posting of a file : known as dpans94.zip for retrieval on the Internet. : When expanded this .zip file yields the following three files: : dpans94.doc Microsoft Word for Windows 2.0 format, : produced by Word 6.0 for Windows. : dpans94.txt This file you are reading now : notice.txt a file which reads as follows: : The original versions of these files are available via : anonymous FTP (login=anonymous, password=email-address) : from ftp.uu.net which is accessible 24 hours per day by : any host whose IP address has a valid domain name that : can be determined by the that server using inverse DNS. : ftp://ftp.uu.net/vendor/minerva/x3j14/dpans94.zip I downloaded the dpans94.zip and tried to read the doc with OS/2 v3.0 IBM Works word processor. It supposedly imports Word 1.x and 2.x format documents. All I could access and read was the first three pages. Has anyone been able to read the document inside the zip from either Word 6.0 or another word processor? I am wondering if it is a bad copy of the document, but not the zip file. ==John Howard== From: sfp@mpeltd.demon.co.uk (Stephen Pelc) Subject: Re: MPE needs consultants Reply-To: sfp@mpeltd.demon.co.uk X-Posting-Host: mpeltd.demon.co.uk Date: Wed, 8 Feb 1995 11:18:32 +0000 MPE has a vacancy for a Forth contractor to work in North Wales for one or two months. The job will be for a PC or a Motorola processor - design decision not yet made. Please contact me ASAP, and send your CV if MPE does not already have it. -- 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: bevan@cs.man.ac.uk (Stephen J Bevan) Subject: Re: What do you think of FORTH as compared to Smalltalk? Date: 08 Feb 1995 13:20:30 GMT <3gm3a0$1c05@coyote.csusm.edu> In-reply-to: tanksley@coyote.csusm.edu's message of 31 Jan 1995 11:33:20 -0800 In article <3gm3a0$1c05@coyote.csusm.edu> tanksley@coyote.csusm.edu (Billy Tanksley) writes: ... The question was, does Forth provide a basis of OO that is not provided by language X, where X is a non-OO language, but is provided by language Y, where Y is an OO language. So what is the answer for some values of X and Y? >Which is easier to understand/write is a subjective issue, so I'll >leave that alone. Perhaps the size of a FORTH OO extension is less >than that of a C version, but it isn't clear to me that it is that >important unless your application is small relative to the size of the >OO extension. Not really true. Your application has needs that are different from any other (non-trivial) applications, therefore (as a "true" (: Forth programmer) you modify your OO package. In principle I agree, but in practice I think it is somewhat different. For example, consider simple stream IO. Sometimes I need to be able to read and write to a file, sometimes it is just read or write. I could modify/reimplement the IO library to take advantage of this but -generally- I don't since the cost outweighs the benefits. Similarly I believe that -generally- the cost of modifying an OO package would outweigh the benefits. ... Tell you what, though; I'll provide _specific_ examples. Compare Objective-C to the OO extensions I posted. Both do similar things, within the limitations of their base languages (yes, Forth does have limitations :); Indeed, I consider it an apples to oranges comparison and hence not one worth pursuing. However, if you insist on this form of comparision I'd suggest replacing Objective-C with an OO variant of Turing built using TXL. If you want a reasonable fair comparison, compare one of the Forth OO extensions with a Scheme OO extension (see comp.lang.scheme FAQ for details of Scheme OO extensions). Why is this fair when the Objective-C one wasn't? Both Scheme and Forth have little syntax, are typeless from one perspective, and have mechanisms inbuilt for extending the language. From: dnw@williams (David N. Williams) Subject: Re: X3J14 TC Document Posted Date: 8 Feb 1995 14:04:22 GMT Reply-To: David.N.Williams@umich.edu John Howard (jhoward@solar.sky.net) wrote: : I downloaded the dpans94.zip and tried to read the doc with OS/2 v3.0 IBM : Works word processor. It supposedly imports Word 1.x and 2.x format : documents. : All I could access and read was the first three pages. Has anyone been : able to read the document inside the zip from either Word 6.0 or another : word processor? I am wondering if it is a bad copy of the document, but not : the zip file. I was able to read the document with Macintosh Microsoft Word 6.0. I have not (yet) attempted to print it. :-) --David _ __ _____________________________________________________________ (_\(__ _|__) David N. Williams Phone: 1-(313)-764-5236 __|___ Physics Department Email: David.N.Williams@umich.edu \ |:-) University of Michigan \| Ann Arbor, MI 48109-1120 From: greg@minerva.com (Greg Bailey) Subject: Re: Can you compile a definition inside another? Date: Tue, 7 Feb 1995 23:09:30 GMT In article <3h87co$r8g@oclc.org>, aph@oclc.org (Andrew Houghton) says: > >I have the need for being able to compile a definition within >an existing definition. For example: > > : abc > : def + 3 * ; > : jkl - 3 * ; > 1 0 rot if def else jkl then > forget def > ; > >Obviously this will not work. What I want "abc" to do is to >create the definitions for "def" and "jkl" and then destroy >those definitions before "abc" finishes executing. I'm not >looking for nesting, in particular. So "def" and "jkl" can >exist in the same dictionary as "abc". Does anyone have any >ideas? Please don't tell me to put "def" and "jkl" outside >"abc". It doesn't solve the burning question: Can you >compile a definition inside another. Thanks for your help. You answer your own question. 3.4.5 Compilation explicitly says "A program shall not attempt to nest compilation of definitions." One of the main reasons for this restriction, by the way, was the introduction of locals. You can certainly make something which is logically equivalent using EVALUATE. In particular, a definition, while it is being executed, can cause the compilation of other definitions using EVALUATE at execution time. The word EVALUATE may be used as well to obtain execution tokens for the new definitions; and, if the system supports FORGET, EVALUATE may finally be used at execution time to delete the definitions just made. If you have a real need to synthesize source at execution time and compile transient definitions for local use, as for example many sorting packages have done for the past thirty or more years, this is the most portable way to accomplish it. From: penev@pisa.rockefeller.edu Subject: Re: ATHENA FORTH Information Date: 7 Feb 1995 15:25:16 -0600 On Tue, 7 Feb 1995 aph@oclc.org wrote: > Here is the problem. Define the following: > > : foo 1 : drop ; > > perspective, but I'm not sure. When I type the above into PFE, the closest > thing to a ANS FORTH, I get: > > Error: "" control structure mismatch > foo hello ." hello" cr ; > ^ > > If I change the definition of foo to: > > : foo 1 : ; > > and then type in "foo hello ... cr ;" then it works however, with the side > effect of leaving 1 on the stack. This is called "stack balancing during compilation." I'm pretty sure the standard allows non-stack balanced compiles (and "unmatched" condinionals), but I don't know whether it prohibits systems, that enforce it. The purpouse of stack balancing is to prevent the beginner from forgetting to balance the conditionals inside a word -- not very FORTH-like attitude. I would trash all of this, as well as the conditional matching checks away from the compiler. -- Penio Penev 1-212-327-7423 From: jimmaas@aol.com (JimMaas) Subject: Federal Express Bug Date: 8 Feb 1995 10:53:50 -0500 Reply-To: jimmaas@aol.com (JimMaas) Can anyone post details on this? From: lgc@bluemax.jpl.nasa.gov Subject: Re: ATHENA FORTH Information Date: 8 Feb 1995 11:27:11 -0600 > Some of this stuff is interesting ... excuse me if I don't know >the rules or have forgottent them ... can I post some of this >correspondence to my Forth conf on the Well? No problem as far as I'm concerned--I think that Greg has comp.lang.forth on the ansforth list, so the posts to ansforth should be freely distributable. --Loring From: tanksley@coyote.csusm.edu (Billy Tanksley) Subject: Re: OOF-32 for 486s announcement Date: 8 Feb 1995 10:16:26 -0800 (Zsoter Andras) writes: >Billy Tanksley (tanksley@coyote.csusm.edu) wrote: >> Um, could you possibly make a lesser version for those of us without 486 >> (I mean, for the 386)? I'd like to try it out-- do you _really_ need >> those one or two 486-only instructions? >I do not have a 386 (nor all the documentation for it) [strange but there are >only 286 and 486 machines around] but most probably I can make a work >around [I don't "really" need those instructions] then we will see. Thanks! BTW, sorry if I sounded a little haughty-- that was just anxiety :). I'll also test OOF on a Pentium as soon as the college lab gets theirs set up, if you like. >I hope you don't mind to wait for a few days, probably I can make an upgraded >version and post again. Don't mind at all! >Andras -Billy From: tanksley@coyote.csusm.edu (Billy Tanksley) Subject: Re: What do you think of FORTH as compared to Smalltalk? Date: 8 Feb 1995 10:30:35 -0800 bevan@cs.man.ac.uk (Stephen J Bevan) writes: >tanksley@coyote.csusm.edu (Billy Tanksley) writes: > ... The question was, > does Forth provide a basis of OO that is not provided by language X, > where X is a non-OO language, but is provided by language Y, where Y is > an OO language. >So what is the answer for some values of X and Y? :) > >Which is easier to understand/write is a subjective issue, so I'll > >leave that alone. Perhaps the size of a FORTH OO extension is less > >than that of a C version, but it isn't clear to me that it is that > >important unless your application is small relative to the size of the > >OO extension. > Not really true. Your application has needs that are different from any > other (non-trivial) applications, therefore (as a "true" (: Forth > programmer) you modify your OO package. >In principle I agree, but in practice I think it is somewhat >different. For example, consider simple stream IO. Sometimes I need >to be able to read and write to a file, sometimes it is just read or >write. I could modify/reimplement the IO library to take advantage >of this but -generally- I don't since the cost outweighs the benefits. >Similarly I believe that -generally- the cost of modifying an OO >package would outweigh the benefits. ...unless the OO package was simple enough. My point. > ... Tell you what, > though; I'll provide _specific_ examples. Compare Objective-C to the OO > extensions I posted. Both do similar things, within the limitations of > their base languages (yes, Forth does have limitations :); >Indeed, I consider it an apples to oranges comparison and hence not >one worth pursuing. However, if you insist on this form of >comparision I'd suggest replacing Objective-C with an OO variant of >Turing built using TXL. I was given C originally. I guess I can handle switching languages :), but I'd rather do one I've _heard_ of before. I've heard of TCL-- is that similar to TXL? Really, I'd like to finish this off-- C is a true general purpose language that we can agree _does not_ have "the basis of OO". I see no need to muddle things up by switching to some other language now. >If you want a reasonable fair comparison, compare one of the Forth OO >extensions with a Scheme OO extension (see comp.lang.scheme FAQ for >details of Scheme OO extensions). Why is this fair when the >Objective-C one wasn't? Both Scheme and Forth have little syntax, are >typeless from one perspective, and have mechanisms inbuilt for >extending the language. That would be a fair comparison. However, all we would be proving is that Forth and Scheme have _a similar amount_ of the basis of OOP. That isn't the question. We need to compare different things, because of the requirement for _controls_ in any investigation. There is no requirement for fairness, because this debate is not about Forth providing something no other language does. I stand by my question-- if you'd rather not use Objective-C, though, go ahead and use some other OO extension to C. I'd rather be able to see things like source, development time, and development cost, but if they aren't available, oh well. If you just don't like C, how about picking some other language that we can agree does not have the basis of OO? -Billy From: phil@3do.com Subject: Re: ATHENA FORTH Information Date: 8 Feb 1995 14:15:52 -0600 > Here is the problem. Define the following: > : foo 1 : drop ; Yes, that will break on some Forths for the reasons others have mentioned. Will the following alternative work on all ANS compliant Forths? : foo2 1 >r : r> drop ; It avoids the problem of changing the stack depth between : and ; . Phil Burk Delta Research From: greg@minerva.com (Greg Bailey) Subject: Re: ATHENA FORTH Information Date: 8 Feb 1995 14:43:30 -0600 Phil Burk wrote on Wed, 08 Feb 95 12:14:51 PST : > > Here is the problem. Define the following: > > > : foo 1 : drop ; > > Yes, that will break on some Forths for the reasons others have mentioned. > Will the following alternative work on all ANS compliant Forths? > > > : foo2 1 >r : r> drop ; > > It avoids the problem of changing the stack depth between : and ; . > > Phil Burk > Delta Research I would expect the above to execute, but again the only action you can expect colon to have taken by the time it returns is the parsing of the new definition's name and the beginning of its compilation. In particular the remaining code in the example, such as the dot-quote and the semicolon, will not have been parsed nor compiled. Therefore, if the intent of foo and foo2 is to retrieve the saved value *after* the definition in question has been compiled to completion, this will not achieve that intent. Only by nesting the interpreter, using EVALUATE or LOAD or equivalent, is it possible to surround a complete compilation process. Greg Bailey | ATHENA Programming, Inc | 503-621-3215 | ---------------- | 24680 NW Dixie Mtn Road | fax 621-3954 | greg@minerva.com | Hillsboro, OR 97124 US | From: snf_dw@debet.nhh.no Subject: Forth vs C++ (was: parameter passing & a lot else) Date: 8 Feb 95 19:43:11 MET In article <3gvifh$ppa@ixnews2.ix.netcom.com>, dcwyland@ix.netcom.com (David Wyland) writes: > > As an operating system command language, FORTH is great. It allows you > to wiggle the system, which is all important when you are trying to make > some hardware do something. That's why it is so amazingly effective in > embedded control and hardware test environments. You can make the > hardware do what you want, quickly. >... > As an operating system, FORTH is not so good. It has not been viewed >... > As a "language," FORTH is also not so good. Why? Because a "language" > is a ***Means of Communicating.*** Computer languages are ambiguous in > this area. Are we communicating with a human or a machine? FORTH as a > command language communicates with the machine, so to speak. Other > computer languages (Basic, C, FORTRAN,etc.) communicate ***Between > Humans.*** As a communication language, FORTH is not as good as Basic, > C, or other langauages. ***It is not as easy to read.*** > Rather than give the (usual?) querulous response to this, I would like to ask others to try to focus on the criteria for excellence that David Wyland is basing this on, and ask the hard questions: Why is it important to use a computer language to communicate between human beings ? (Incidentally a major design goal of Simula, the first OOPL, originating at Norsk Regnesentral, Oslo.) Has the Forth community been attempting seriously to develop Forth to serve this goal? (Simula '67 was developed with precisely this goal as one improvement over the earlier first version.) David gave some but not all answers to the first question. Another answer is that universities demand a particular kind of readability related to short student exercises and examination requirements, with some pretence to structure and discipline (but not much, e.g. C++). The reason I ask you to think about the answers, is so lthat you may ultimately realize that the *questions* are important. The usual response to claims that Forth is not readable are _defensive_ in the technical sense invented by Chris Argyris. The improvements and discussions around the readability of Forth are in his terminology "single loop learning routines" that signal an unwillingness (due to faulty organization and goal articulation) to address the real questions that actually threaten (and promise) to change things. The correct response is to ask the hard questions that lead to "double loop learning" which re-examines the basic criteria of excellence. > > FORTH suffers the same problem as APL, another very powerful but densly > arcane language. I think that is a common perception out there (outside the myopic Forth world). The Forth community could I think do a great deal to remedy the perception, but insisting that e.g. Forth is really more powerful because it leads e.g. to simple and elegant chip designs is to give a correct answer to the *wrong problem*. > currently written. FORTH uses a list concept only in the sense that a > word is a list of operations. And the list of items in the word is not > a list of equations with a few standard operators, it is a list of > operators where each operator is one of a hundred or more from the > current dictionary. You have to know what ALL the operators mean to > understand the list of items in the FORTH word. > > FORTH was not developed to move and combine words in a memory. It was > developed to move a telescope. The basic FORTH element is not an > equation which changes data in memory, it is the command word which > causes the system to ***do something,*** just like the commands you type > in from the keyboard to DOS or Unix. FORTH's power comes from being able > to extend this command language by making more powerful command words > out of existing words. FORTH is a machine design language: you assemble > new "machines" in the form of new command words. This is another reason > that it is so popular with hardware designers. > I think few Forthers will agree that the buggy, side-effect-ridden code that results from moving stuff around in memory will have much role in the future. But the Forth community has failed to present Forth as the simplest way to avoid risky side effects that bring down large projects. We have left the field wide open to C++, which is a technically inadequate OOL, to sell its second-rate solutions to side effect problems to the universities (scope, local variables, constants, stack-framed structures, the OO approach itself, etc). People out there are battling to understand and use C++ consistently without introducing new problems. There is an awful lot of traffic on the C++ News conference, much of it not debating principles as here, but focussing on how to make it work at all. Yet, C++ has made a clean sweep of the engineering faculties of the world, as well as computer science in its software and hardware-oriented varieties. Many of you who've used Forth extensively, such as David Wyland, seem to be unaware of the fact that stuff on the stack in a tested word (routine) gets clobbered less often than a poorly named variable. I.e. a major reason for Forth's reliability and speed of development is not generally known or understood. Why? Because Forth's strategic (rather than technical) advantages have been largely ignored. Experience has shown, as David Wyland correctly points out, that Forth is good for instrumentation and control because it was originally developed for that purpose. But experience is not strategic analysis. The issue I am trying to get discussed here is not why Forth has succeeded in certain areas in the past. It is to look at how Forth could succeed unexpectedly in totally new areas in the future. Because if Forthers will not do that, Forth will not grow like C++. A potential area for Forth success, largely unexplored, is for writing very large software systems. There are many reasons why I think it is good for that. But the discussion I'm looking for, is not to follow up my own particular opinions. Rather, i would like to see people putting forward intelligent reasons why Forth could succeed in a variety of new roles, and what criteria would have to be understood and met for that to happen. My point is to ask the hard questions, the ones that will change Forth's role in the world, rather than defend the tiny niche it has at present. In the end, defence may not be enough even to maintain that. > > The irony of all this is that the rest of the world is moving much > closer to FORTH with object oriented languages such as C++. An OOP > object is a little stand alone program, a little machine that responds > to command messages sent to it. OOP system design is designing these > object/machines and setting up communication between machines to do some > overall system operation. FORTH is conceptually there, except for the > machinery of public/private and inheritance. And Markus Dahm's pure object oriented Forth not only has all that machinery but also implements them consistently and safely in a way that C++ does not. > > So, how does this tie back into parameter passing and whether FORTH is > better than C? By identifying that FORTH and C (Basic, FORTRAN, etc.) > are different in kind. You can compare C, Basic, FORTRAN and ADA. > Comparing C and FORTH is comparing apples and oranges, as discussed > above. > > I use C or Basic for a project involving several people, for standard > data processing and number crunching, or if I am writing code that will > be maintained by someone else such as the customer. These are > appications where human to human communication are important. > > I use FORTH if I need to make something work quickly and well, typically > an embedded control or test project. (I suspect this is why FORTH is > the boot language for SUN: it helps you to get the hardware working if > it is broken, then you bring up Unix and run C code!) These are > applications where control of the machine is important, where I am > designing a machine to be worked by humans. > I think Forth is something much more general in its potential, largely unrealized because of poor organization of the Forth community. Like complex function theory, Forth should be adapted to widely different applications requiring broad knowledge of computer science and engineering. Just because complex function theory is great for electronic engineering doesn't mean it isn't useful in other fields. Fundamental methods that fill logical gaps and weaknesses have many applications. But first, someone has to show their advantages. The history of math shows that can take a very long time. It seems to me that Chuck has been working in the right direction technically, producing ever shorter, more elegant and powerful Forth systems and relating their development to elegant processor development. That seems to me analogous to the abstractions into pure mathematics that tend to precede re-application of practical methods in totally new areas. First, you have to strip the method to its most basic essentials, studying in detail what you need and what is just baggage that hangs on from the original application. Only when you have captured the essence of the method, its abstract and minimal form, have you freed it from the niche that it came from. Only then can you see easily the enormous fields where the more abstract form provides very rapid new solutions. If you want a practical example, try first proving all those trig formulae without complex numbers, then try the same using complex numbers. Chuck is doing what you all ought to be doing with him -- instead of claiming that Forth is the best "language" for everything, he is working at abstracting it in terms that leave us in doubt whether he views it as a language at all. Is it a virtual machine? Is it an intermediate compilation code? Is it an alternative machine architecture ? Is it really a parallel instruction set ? Is it a mathematical object that is essentially new ? With each abstraction there is an accompanying new paradigm, as with the first Forth chip. That search for abstractive power should, if resources are going to be found for continuing the search, be mixed with some appreciation of the criteria for success, an appreciation that Chuck's namesake, Charles Babbage was rather short of. I don't know whether that is flame-worthy or not, but there's an awful lot of ice and snow up in these here mountains, so fire away anyway.... Rgds, David Walker snf_dw@debet.nhh.no From: Glenn.Linderman@SanDiegoCA.ATTGIS.com Subject: Re: ATHENA FORTH Information Date: 8 Feb 1995 18:48:37 -0600 Reply-To: Glenn.Linderman@SanDiegoCA.ATTGIS.com -> To: phil@3do.com (Phil Burk) -> Cc: ANSForth@minerva.com -> From: greg@minerva.com (Greg Bailey) -> -> Phil Burk wrote on Wed, 08 Feb 95 12:14:51 PST : -> -> > > Here is the problem. Define the following: -> > -> > > : foo 1 : drop ; -> > -> > Yes, that will break on some Forths for the reasons others have -> > mentioned. Will the following alternative work on all ANS -> > compliant Forths? -> > -> > -> > : foo2 1 >r : r> drop ; -> > -> > It avoids the problem of changing the stack depth between : and ; . -> > -> > Phil Burk -> > Delta Research -> -> I would expect the above to execute, but again the only action you -> can expect colon to have taken by the time it returns is the -> parsing of the new definition's name and the beginning of its -> compilation. In particular the remaining code in the example, such -> as the dot-quote and the semicolon, will not have been parsed nor -> compiled. Therefore, if the intent of foo and foo2 is to retrieve -> the saved value *after* the definition in question has been -> compiled to completion, this will not achieve that intent. Only by -> nesting the interpreter, using EVALUATE or LOAD or equivalent, is -> it possible to surround a complete compilation process. -> -> Greg Bailey | ATHENA Programming, Inc | 503-621-3215 | -> ---------------- | 24680 NW Dixie Mtn Road | fax 621-3954 | -> greg@minerva.com | Hillsboro, OR 97124 US | The way to "surround" a complete compilation process is to redefine both ":" and ";", as in: : foo 1 : ; : oof postpone ; drop ; foo newdef words to implement newdef oof Using foo and oof to surround definitions instead of : and ; and you will get the right effects. --- Glenn Linderman Phone: (619) 485-3339 --- AT&T Global Information Solutions Voice Plus: 8-440-3339 --- Department 7301 ========= FAX: (619) 485-3765 --- 17095 Via del Campo EMail: --- San Diego, CA 92127-1711 Glenn.Linderman@SanDiegoCA.ATTGIS.com From: erather@aol.com (Erather) Subject: Re: X3J14 TC Document Posted Date: 8 Feb 1995 20:05:14 -0500 Reply-To: erather@aol.com (Erather) >>I'm getting the impression that one of the uses I would like to make of it >>would be illegal, namely, to include quoted word specifications for each >>word as comments in my source code. Or not?! > >Julian Noble asked the same question. Since the TC, as far as we have >been told, owns the copyright to the working document, I would suggest >that you address this question directly to TC chair, Elizabeth Rather >(Elizabeth.Rather@minerva.com works) and copy x3j14@minerva.com, for >a ruling. Rules should be as for quoting from any published document copyrighted by someone else: identify your source clearly and accurately. Specifically, in this case, do *not* quote from dpANS6 and claim you're quoting ANS Forth!!! I completely concur with what Greg said about buying yourself an official copy, but with one minor variant: we happy TC members do have official copies, and can quote from it (we have at least that one benefit from all those meetings!). Those of you not on the TC should buy a copy if you want to claim ANS compatibility. Otherwise, read it for information. The electronic copy that we encourage using for on-line docs, etc., is not ANS Forth, so beware of misleading references or uses. Elizabeth D. Rather "Forth-base products and FORTH, Inc. services for real-time 111 N. Sepulveda Blvd. Suite 300 applications since 1973" Manhattan Beach, CA 90266 800-55FORTH -- 310-372-8493 310-318-7130 FAX From: kleiner@navhp1.nav.uni-stuttgart.de (Thomas Kleiner) Subject: Re: doubly linked list in 1 field Date: 8 Feb 1995 08:22:19 GMT In his Article (14143) Richard de Rozario writes: ... > To create a doubly linked list we store the XOR of the > predecessor and the successor in the link field. The first and > last items in the list have a predecessor and successor of some > special value (like zero) that we can recognise as the end of > the list. ... How do you know wether your link contains - a xor b, with a, b != 0 - a xor 0? ... > To process the list we need two addresses: the predecessor and > the current element. So, to process our example list from the ... The point is: you XOR the CURRENT element and its PREDECESOR! Above you said, you would XOR the SUCCESSOR and the PREDECESSOR. So you create a singly linked list with a usesless XOR-overhead! In my opinion the advantage of doubly linked lists is that you can walk through that list back and FORTH ;) starting at any node. In a singly linked list you use the link direction to traverse without overhead. But finding the predecessor requires a traversal from the beginning of the list. And that is why you need two links in a doubly linked list! Thomas Kleiner (Dipl.-Inform.) Universitaet Stuttgart Institut fuer Navigation Keplerstrasse 11 D-70174 Stuttgart Tel.: +49 (0)711/121-3410 FAX: +49 (0)711/121-2755 +49 (0)711/121-3500 e-mail: kleiner@nav.uni-stuttgart.de Date: 08 Feb 1995 21:24:00 +0100 From: clv@clvpoint.forth-ev.de (Claus Vogt) Subject: German Forthmeeting April 1995 X-Charset: ISO-8859-1 The 11th Annual meeting of the Forth-Gesellschaft will take place from 21.-23.4.1995 at Berlin (Germany) Conference language will be German. For more information try to translate the following announcement. - Claus Vogt, for the Forth-Gesellschaft - >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Forth-Gesellschaft e.V. (gemeinnützig), Postfach 1110, D-85701 Unterschleißheim, Tel/Fax: 089/317 37 84 und Forth-Tagungsbüro'95 clv08feb/2 c/o Bernd Hinze, Waiblinger Weg 6, D-12487 Berlin An die Redaktionen für Wissenschaft, Technik, Computertechnik dpa-Berlin z.Hd. Herrn Dirkholz P R E S S E E R K L Ä R U N G Forth-Tagung 1995 vom 21.-23.4.1995 in Berlin. Die 11. Jahrestagung der Forth-Gesellschaft findet vom 21. bis 23.4.1995 in Berlin statt. Der Schwerpunkt "Microcontrolling" umfaßt Vorträge zu Meßtechnik, ISO 9000, einzelnen Controllern (z.B. PIC), zur Sensor- und Aktortechnik und zur Robotik. Im Schwerpunkt "Forth-Systeme und Forth-Prozessoren" werden Entwickler die aktuellen Tendenzen im Markt der Forthsysteme für GUI-Betriebssysteme und im Markt der Spezialprozessoren, wie dem FRP 1600, RTX 2000 und der deutschen Neuentwicklung - dem IX1 - besprechen. Hier werden auch die Auswirkungen des Kooperationsvertrages zwischen Forth Inc. (USA) und MPE (GB) zur Sprache kommen. Der Schwerpunkt "Applikationsentwicklung" umfaßt voraussichtlich Beiträge zu Bildverarbeitungssystemen, speziellen Problemen der Echtzeitdatenverarbeitung, Terminplanung in Forth und neue Techniken der Cross- und Metacompilation. Am Rande der Tagung stellen Firmen und Anwender gemeinsam ihre Produkte aus. Tagungsort ist ein idyllisch am See gelegenes Hotel im Osten Berlins. Die Tagungsgebühr beträgt ohne Ermäßigung 340.-DM incl. Übernachtung und Verpflegung. Für schriftliche Rückfragen steht Ihnen gerne das Forth- Tagungsbüro'95, c/o Herrn Hinze, Waiblinger Weg 6, D-12487 Berlin zur Verfügung. Dort erhalten Sie auch die Anmeldeunterlagen. 22 Zeilen à 70 Anschläge. i.A. - Claus Vogt, Berlin - ## CrossPoint v3.02 ## From: japs@netcom.com (Jim Schneider) Subject: Re: Compilers (Was: FORTH Databases) Summary: An often overlooked benifit of threaded interpreted languages Date: Thu, 9 Feb 1995 06:31:48 GMT In article <791315141.AA04877@jina.rain.com> Tom.Almy@f290.n105.z1.fidonet.org (Tom Almy) writes: > >The only real advantage of threaded code is that it is easier to compile. The >small compiler size made it possible to have complete Forth systems in 8K of >memory, which was important 10+ years ago. > >Tom > Actually, the most important reason to use a threaded FORTH implementation has nothing to do with machine efficiency, but everything to do with *PROGRAMMER* efficiency. I use it because it is very simple to understand, and even simpler to modify. From: Angelus@pascal.acm.org Subject: Re: Forth's reputation Date: Wed, 08 Feb 95 23:56:16 PDT Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII In article <38ijes$2a4@ixnews1.ix.netcom.com>, writes: > Path: hopper.acm.org!natinst.com!cs.utexas.edu!uwm.edu!spool.mu.edu!agate!darkstar.UC SC.EDU!news.hal.COM!decwrl!netcomsv!ix.netcom.com!netnews > From: rant@ix.netcom.com (Ran Talbott) > Newsgroups: comp.realtime,comp.robotics,comp.lang.forth > Subject: Re: Forth's reputation > Date: 25 Oct 1994 09:34:20 GMT > Organization: Netcom > Lines: 15 > Distribution: world > Message-ID: <38ijes$2a4@ixnews1.ix.netcom.com> > NNTP-Posting-Host: ix-sj13-04.ix.netcom.com > Xref: hopper.acm.org comp.realtime:2229 comp.robotics:6473 comp.lang.forth:3527 > > In jfox@netcom.com (Jeff Fox) writes: > > >It would be nice if you put these statements in context. > > Actually, no: it would be insufferably rude to waste bandwidth in > comp.robotics with this little religious war you've started. That's > why I tried to make a concise summary, and be done with it. > > Of course, you seem to be no stranger to insufferable rudeness, > since you persist in trying to stuff words like "denying that there > is an upside to the freedom in Forth" in my mouth... > > Give it a rest, Jeff. You're embarrassing yourself. > > Ran You know, Ran, when a human being gets trapped in a corner, you last response is usually the answer given " You know, I can't tell you why your responses make sense, but, why start a religous war, why do you keep harping on the same subject?. It is simple, you have never really tried Forth, and have an attitude of" It is not what I use, so it must be wrong!". I will tell you what. I will challenge you or anyone else to an intelligent robot control contest. Let's find out what the best programming enviornment is? From: h9290246@hkuxb.hku.hk (Zsoter Andras) Subject: Re: OOF-32 for 486s announcement Date: Thu, 9 Feb 1995 07:51:56 GMT As I was asked to make a version that runs on 386 machines I started to search for a 386 machine and I got hold of one for a while. A few BSWAP in VMI caused the problem but now it is all right. The newer version will run on a 386 machine (even without a 387, but try to avoid floating point instructions because some of them might hang your machine if there is no co-processor -- the system won't use those routines is the NoFPU flag is set to a non-zero value [the setup will do it automatically unless you have some very exotic hardware]. The program is now on taygeta.oc.nps.navy.mil in the pub/incoming/forth subdirectory (but will hopefully be moved to Forth/Reviewed). The old files: oof.zip 177292 bytes ooflst.zip 245450 bytes The new files (run on a 386): oof.zip 178129 bytes ooflst.zip 245953 bytes I hope it helps those who don't have a 486. Please remember that I developed the program for myself and originally it was not intended to be released but many people asked for it. So it is released in the hope that someone can make use of it but nothing is guaranteed. I used the program ONLY on Intel 486DX (TM) processors and I am not sure if they work at all on other machines (at least two 386 one with a 387 and one without it and a Cyrix 486 did not generate black smoke when the program was running). Good luck, Andras P.S.: If you have some success please send an e-mail to me. From: st000533@hrz.th-darmstadt.de (Wolf Lichtenberger) Subject: Re: Operating Systems as a Needless Complication Date: 8 Feb 1995 08:51:25 GMT Billy Tanksley (tanksley@coyote.csusm.edu) wrote: : PC/Geos demo is on arginine.umdnj.edu/pub/geos/publish/*.* . It requires : a machine that can emulate a PC with a very compatible hard disk (it : takes some work to make Linux's DOSEMU do this) and at least one meg of : memory (I recommend two at least). Sounds interesting. Care to tell how u dunnit tweaking ? When i tried the dosemu (0.4) i contended meself with running nc or somesuch.. (after configuring for 2 h 8*) ) : >Sadly enough, the latter are just that, homegrown or alternative, : >i.e. non-mainstream (just barely managed to avoid '..-standard' : >;-) ). If you want to : Well, none of those are really an epithet, really. Everything in the : computing world starts out as being out of the mainstream. : >* just _have_ an OS : >* play with it (endless configuration 8-) ) : >* program with it for yourself or other fans : :) Guilty. Well, my mom uses Geos exclusively for writing her books-- : MASSIVE projects that I doubt MSWord would handle at all in one chunk, : much less on my machine (her 1st book was done when I had a 286-2M; 2nd and : 3rd with a 386sx-4M). Sounds interestinng again. Did she use GeoPublish (not tried yet by me)? AFAR GeoWrite did only Fonts & Pictures, whereas i *do* need footnotes, pagination, table of contents, ... : Also, Geos can run on every intel platform with 512K memory : and ROM support... that's quite a few machines, all of them cheap. : That's supposed to be the draw for programmers-- write and compile your : program once, it'll run on ALL platforms. It works, too-- one of the : programming languages out for Geos was built entirely for the Zoomer (the : author didn't know about the dektop version) but is used mainly by : desktop users. see GEOS reminiscencies below ;-) : >that's great & enjoyable, but regrettably *not* subject of any : >9to5-job i know of in 'real life'. There, you just *have* to use : >an existing system to create app's - mostly the system that the : >app customer got talked into buying at some time in ..the dim : Yes, that's how it goes-- unless you can create the _need_: "you can't : run the CDROM you need unless you get me that CDROM-based OS here." A : Forth OS would be small (I should say _is_ small), but smallness is not a : _need_ for most people :(. Once upon a time, someone here in Germany described programmers as being divided in two factions, namely (translated) "memory wasters" and "bit squeezers" (bit-pfriemler) ... [...] : >That's what i remember offhand; ask for details if interested; also : >if GEOS or GEM3.1 are relevant (had them, but didn't do so much : >with them). : I'd like to hear it. (I won't flame, I promise.) OK, here goes [ducking low]: Installation smooth (even *nice* installation scheme, would allow for really easy conversion to media of different capacity. Really *nice* user interface - as i learned later, modeled after motif (sic !) The usual Applets, this time (at 1st sight) quite a bit more usable than their Windows counterparts. On second thought, (in comparison to Windows - pardon me) two features were missing that i greatly appreciated in W. : - an OS-defined help system - Im- & Export of rich text formats in GeoWrite (maybe cured in G.Publish) Other than that, i didn't quite get how to multitask DOS prg's under GEOS (maybe i got that wrong and it should be run one DOS prg & many GEO-apps in parallel or was it ?) At least, i wondered (after marveling at interface & resource req'ment): where are *real* applications? And when they didn't come: where's the SDK ? (make that: Software Dev.Kit, sold *dirt*cheap* to attract SW developers and create a GEOS maket share !!!!!!) Well, since the SDK runs AFAR in another environment, the only app i know of i Borland Quattro (was that 'Lite' ?), and PR/ads/tech articles in mag's were - if anything - scarce, i didn't do anything but "nice, but wait & see" [returning to 'upright walk' ;-) ] : >.. as long as the trend of ever-decreasing prices for faster : >hardware (or ever-increasing speed for same price) continues. : >The problem here is, that the >>in<< app's require on average : >a faster machine than you have or can afford before next year. : This is only for the elite, though. Computers still aren't cheap enough : for everyone. I think we're going to reach a breakpoint soon that will : _reduce_ the power in each machine and increase dramatically the number : of machines; past examples of this abound : (mainframes->minis->micros...). Any other opinions? Maybe if another paradigm change occurs - f.e. "desk computers" to "personal computers" (worn or lugged around), perhaps. I wonder, though, what will happen to today's extensibility with cheap ISA (or other) slot cards galore - should that once become "my machine has 6 PCMCIA slots, all filled with essentials." 8-O ? : >: ("Visual C++ may be totally inextensible, but at least : >: it has.... ** THE CHISELED LOOK**!") : >Like everyone, i'd like to eat my cake & have it, too; so if someone : >installs the chiseled look and it's not negatively (speed & : >stability !) affecting my system or work, then ok, let it be... : >(ok i'm one for good looks as well, but within limits !). : >What's more, it _is_ a step further from the specialist front panel : >to an ergonomic, intuitively usable interface - at least now : >it seems so. : Bah. Get a real OS ;). Chiseled look indeed. All Motif system have Have it :-) . Look again at my OS encounters table above - at least 2 OSs running mwm there ;-]. : had that for years; windoze,s UI is disgustingly behind the times. : Always has been, too. Humbug. :) : -Billy Thus spake Zarathustra - & how right u are... -Wolf -- /`/`_=_____ _/ [the mad gourmet c'scientist] _/ From: rant@ix.netcom.com (Ran Talbott) Subject: Re: parameter passing Date: 9 Feb 1995 13:39:19 GMT In <3h9su9$cmd@ixnews3.ix.netcom.com> dcwyland@ix.netcom.com (David Wyland) writes: >My point in my original comment was that FORTH is more than a >conventional language like Basic or C. It is an extendable superset, >and it is different in kind in terms of how you program in it. It has >an additional dimension. > >In standard languages, you LEGO block standard words and operators >together. In FORTH you program by extending the lnaguage. You have >more words to remember (including the ones you defined) in order to >understand a line of FORTH code. This is the price you pay for power. No, this is the price you pay for inexperience: all five of the HLLs you say you've programmed in include the ability to define functions that are syntactically indistinguishable from the "standard" ones. If you've been writing programs in the other four by simply piling up huge masses of spaghetti code, instead of breaking it down into manageable subroutines, it's no wonder you've found that you fared better in Forth. >You could make FORTH look like Basic or C by chopping back its words and >making it unextendable. I don't know whose C compiler you've been using, but Borland's C for DOS has in excess of 500 words in its base "vocabulary". When you add in support for Windoze (which happens quite seamlessly, despite your contention that C is "unextendable"), you're probably well over 1000. Let me know when you start "chopping back": it might be fun to watch... Ran From: paysan@Informatik.TU-Muenchen.DE (Bernd Paysan) Subject: Re: redefining defining words Date: 9 Feb 1995 13:15:02 GMT X-newsreader: xrn 7.00 In article <79563@sdcc12.ucsd.edu>, ir230@sdcc3.ucsd.edu (john wavrik) writes: > > >Loring Craymer writes: > The second definition >> >> : foo 1 : ; >> >> avoids conflicts between the data and control-flow stacks. > > The definition of foo should not be problematic. : (colon) is a >word which is not immediate -- so its address (or its "semantics") are >compiled in the definition of foo. > > The execution of foo should not be problematic. The 1 is put on >the stack before any control information produced during the execution >of ":". When the execution of ":" terminates (because of a semi-colon >in the input stream) any control information is removed. But : doesn't terminate, when it finds a ;, it terminates after it compiled the word header and set the interpreter into compiling state. You have to continue (eg. with EVALUATE or LOAD) to reach a ;, then you're back in interpreting state and any control information is removed. BTW, in ANS FORTH control information of : might be used for the implementation of locals (; finds out that there were locals, and removes the temporary wordlist for the locals). gforth uses the control information of : this way. The reason is if you want to use : for automatic creation of words. Because of speed reasons, you might not want to use CREATE DOES>, eg. for producing a word that adds an offset (structures): : field: ( offset len -- offset' ) over >r : r> postpone Literal postpone + postpone ; + ; as compared to : field: ( offset len -- offset' ) Create over , + DOES> @ + ; In a native code Forth, the former might produce one instruction (that is inlined when compiling, eg. add ,eax, even if combinded with @ and an optimizer move [eax],eax), the latter always runs through DOES>, and wastes space and time (a call might be longer than to add a short immediate). -- Bernd Paysan "Late answers are wrong answers!" My Homepage From: gml@ag.pu.ru Subject: ct: Re: doubly linked list in 1 field Date: 9 Feb 1995 14:31:01 GMT In his article Thomas Kleiner wrote: >In his Article (14143) Richard de Rozario writes: ... >> To create a doubly linked list we store the XOR of the ^^^^^^^^^ >> predecessor and the successor in the link field. The first and >> last items in the list have a predecessor and successor of some >> special value (like zero) that we can recognise as the end of >> the list. ... >How do you know wether your link contains > - a xor b, with a, b != 0 > - a xor 0? a xor 0 = a ; XORed list traversal stops at the end and at the beginning > ... >> To process the list we need two addresses: the predecessor and >> the current element. So, to process our example list from the ... >The point is: you XOR the CURRENT element and its PREDECESOR! to calculate the address of SUCCESSOR: C = P xor S S = P xor C P = C xor S >Above you said, you would XOR the SUCCESSOR and the PREDECESSOR. >So you create a singly linked list with a usesless XOR-overhead! >In my opinion the advantage of doubly linked lists is that you can walk >through that list back and FORTH ;) starting at any node. With enXORed lists you can walk back and forth, but your pointer has to be the (PREDECESSOR,CURRENT) pair. You have to know addresses of TWO nodes to go in some direction. >Thomas Kleiner >e-mail: kleiner@nav.uni-stuttgart.de --- Michael L. Gassanenko gml@ag.pu.ru or gml@gym.samson.spb.su ------------ --------------------- From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Subject: Re: doubly linked list in 1 field Date: 9 Feb 1995 15:16:49 GMT Richard de Rozario writes: |> Sounds like your disaster made you avoid using doubly linked lists Not consciously. Of course, when I evaluated alternatives, I considered alternatives employing doubly linked lists as less desirable than I would have without my previous experience. However, if they would have been the solution of choice, I would have used them. But, in fact, I don't even remember a case where such solutions came into closer consideration. |> What sort of a disaster was this? It was an editor. I wanted to represent the buffer as a doubly linked list of lines. Of course, the principal error was not the use of a doubly linked list, but splitting the buffer into lines (I did not want to make a vi-like line oriented editor, but something like the Norton editor or a simple version of emacs). But I think that the use of the doubly linked list complicated the thing so much that it became so hard to debug that I gave up in the end (it just was a fun project, anyway). I don't think the complications arose from the cute implementation. On the contrary, this made things simpler in some cases. E.g., a position in the list is represented by two addresses. When they are on the stack, the direction of walking the list can be reversed with a simple SWAP. In article , smcl@sytex.com (Scott McLoughlin) writes: |> One of |> the niftiest applications of 2linked lists I've seen recently |> is H. Baker's "non-copying copying garbage collector". Heap |> objects are stored on two doubly linked lists, each representing |> the traditional semispace. The "copying" consists of unlinking |> reachable objects from the "from space" list and sticking them |> on the other list. What is left on the list is reusable memory. |> Using the doubly linked list gives _part_ of the benefit of |> a copying gc, in that the time is proportional to the amount |> of live data. In contrast to many other defenders of the doubly linked list, Scott gives a concrete example. The idea is cute, but would you use it when implementing a garbage collector? Alternatives that come to mind are copying garbage collectors, and if this is not possible (e.g., for a "conservative" garbage collector), a mark-and-sweep garbage collector. In theory, mark-and-sweep has a complexity disadvantage, but in practice you can make the constant factor on the sweep phase small enough that it is competitive. - 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 From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Subject: Re: ATHENA FORTH Information Date: 9 Feb 1995 15:23:16 GMT In article <9502072113.AA11974@fssun09.dev.oclc.org>, aph@oclc.org writes: |> I'm not sure whether doing the following is legal ANS FORTH so I was |> looking for someone to provide an interpretation as to whether it is |> legal and if not why not. |> |> Here is the problem. Define the following: |> |> : foo 1 : drop ; [...] |> foo hello ." hello" cr ; It's not legal in ANS Forth. Upon the definition of "hello", the second ":" pushes an item called colon-sys on the stack. A colon-sys has an undefined size. The ";" at the end of "hello" expects a colon-sys and wants to remove it. However, your code drops (a part of) the colon-sys in the meantime. The results are undefined. - 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 From: znmeb@plaza.ds.adp.com Subject: Re: Compile-time Checking Date: 9 Feb 1995 10:20:41 -0600 In article Raul Deluth Miller wrote: : Gordon Charlton: : ........... I have attempted to use a Forth which will be familiar : to most readers, and is often referred to as Classic : Forth. Discussions of this nature are not possible within the : constraints of the ANS standard, and I feel there is a need for : some sort of formal definition of "Classic Forth" which can be used : to make discussions like this less ambiguous. It would be very nice : if we could all agree on a baseline implementation of Forth which : is consistant with the standard, but bites the bullet on all those : issues that the ANS committee had to gloss over to allow different : strategies for different processors. : : Hmm... Probably should be a Von Neumann machine (code and data in same : address space) -- Harvard model adds complexity. No? : : On the other hand, I can see a handful of distinct implementations, : depending on threading. Personally, I think such a reference model : should be direct threaded, (since the stated design goal is "middle of : the road compromise machine") -- token threaded is a reasonable rough : equivalence (call it opaquely direct threaded). : : Um... cells should be aligned on cell addresses (for compatability : with RISC implementations). : : And then there's a batch of "arbitrary constants" people usually : ignore... : : On the other hand, there's EFORTH -- probably better than anything I'd : want to come up with. Laxen-Perry model for the 80x86 probably comes close, as does Martin Tracy's ZenFORTH, at least the version I'm using. A true "Classic" FORTH would undoubtedly be wedded to a 16-bit two's complement architecture; perhaps both cell and byte addressing could be made to work. You'd be limited to a 64K space in either case. But why? I believe the future of FORTH lies within the ANS standard, not in the past standards (figFORTH, F79, F83, etc.). The benefits of the ANS standard far outweigh the temporary inconveniences involved in switching one's thinking in the direction of the standard. -- M. Edward Borasky (znmeb@plaza.ds.adp.com) How to Stop A Folksinger Cold # 5 "Where have all the flowers gone..." Beats me.