Re: Speaking of Forth..

A.) A stack is a software structure. As long as you have RAM and a pointer to RAM, you can make a stack.

B.) FORTH IS an interpreteted language. The COSMAC's wierdness makes implementing a FORTH interpreter rather easy. The later model 1805 used FORTH primitives in it's machine code, an acknowledgement , I guess, of how the COSMAC's were being used.

C.) In the data sheet form HARRIS, they describe a GOSUB/RETURN scheme that is exactly the same as the return stack scheme in FORTH. One register points to RAM - this is the return pointer. One register points to a "CALL" routine. One register points to an "EXIT" routine. One register is designated the program counter.

To call a routine, you pointed the P nibble (the register that controls which of the 16 registers is the Program Counter) to the "CALL" register. "CALL" saved the Program Counter on the return stack, loaded your subroutine in the Program Counter and ended by pointing to the Program counter. The end of your subroutine pointed to the "EXIT" register. "EXIT" undoes "CALL".

and...

D.) Dude! You're putting WAY too much energy into this, I'm missing the point.

FORTH was made to control machines. I wouldn't write a spreadsheet in FORTH, but if I want to control a machine, FORTH makes fast, compact code, AND I can write the program directly to the machine. None of this write it on a PC, burn it in the chip, debug it and start again, stuff. I think this is FORTH's biggest advantage.

FORTH is no more or less incomprehensible than C. : ; is no more difficult than { }. With FORTH, the shorthand was done to save space in the kernal. I don't know what C's excuse is. If you want readability, stick with PASCAL.

FINALLY....

If you don't like it, don't use it. Stop putting people down for not being you!

Yes, overloading and such for C.

The same double edge in Forth. There are many swords here, most have at least one edge.

Close enough.

I don't recognize the ** as a commonly available operator (integer at least), but really no biggie, if I needed it I could easily write it to work with your code exactly as written.

Yes. As would "**", if I wanted to add "**" to my code to run your code untouched.

In Forth new words take up one cell to instantiate a call in the final program. What would it be in C? Wouldn't there be an opening of a stack frame, transfer in of variables, a machine code call, a transfer of variables out, and a stack frame clean up?

Oh, I hadn't thought about the C #define in years. Essentially a one-pass, preprocessor substitution, isn't it?

Many (me too) like to redefine CONSTANT in Forth to be IS. Gives more readability. e.g.

360 IS COMPASS-LIMIT

Mostly what we've been discussing above falls into "nuances" of the languages. What do you think of the suggestion Forth programmers are faster than C programmers?

If you can show me were I said Forth programmers missed deadlines, I'll consider your argument. I believe I said, Forth is an amplifier. A good programmer can write very good code, a bad programmer can write really bad code.

Yes, I seem to be saying that. It's not a double standard if the Forth programmers actually did finish long ago and are sitting on the beach with their toes in the sand, eh? Mike mentions an actual event: three programmers, three months, asking for many times that more to finish; Mike three days, done. That would be long gone, wouldn't it?

Charles Moore, the inventor of Forth, often says he looked at his life, and how program developments were taking several years to finish. He thought to him self, that means he's only going to get to work on 10 or so projects in his carreer. He says he invented Forth with a a hope he might work on hundreds of projects in his life.

I believe now it is because you cannot concieve that using one language vs. another, in a given domain of problems, can cut programming time by

10x.

Didn't you add the clown part?

I believe what Mike meant by "flailing" is they were: trying lots of approaches, finding lots of problems, making lots of noise, having lots of meetings, and complaining loudly how hard a problem it was, saying it would take about another year. I wouldn't characterize that as "clowning" but as pretty much a "normal product cycle".

If you think they are clowns, because Mike actually wrote a program which did what they were trying to do in three days, well..., that's your interpretation, isn't it?

No no. This is not a hypothetical. It is not an issue of they "can't". This is an actual experience, something that happened - history! There is no implication here about what they can and can't get done. There is only the fact that after months of trying, a team of three programmers working in C "didn't" get done.

Again, "can't" doesn't apply. "Didn't" is all that matters.

Mike got tired of watching them drawing their salaries and sliding the project out, so he "did" what they were saying they couldn't do, and it only took him a few days to do so.

Show me where I did that please, particularly the clown part.

The reason you've encountered resistance, is because of your injection of straw men into the argument. What you have above is that you've tried to state you opinion that his opinion is wrong. Which would be fine if it was his opinion. It isn't.

You create a strawman when you say, "Blueeyedrop's characterization that useful work using C is a rare event". I assure you, blueeyedpop's holds no such position. Go back and find evidence of your claim about his claim. Show me where.

I don't think he has anything against C. It's just not what he prefers, and he has a reason, and it is based on his personal observation, and the history of his own personal experience.

I don't have anything against C. I have about the same experience as he does, where Forth and C were compared.

I think I can speak for both of us if I say, C is fine, and ordinary. I might even go further and say, I'm glad C is out there. It fits many programmers thinking much better than the language I prefer, so indeed, they can be programmers in some language, even if they aren't as fast as I am.

But they can never hope to get things done as quickly, or as elegantly, or with as little resources, etc., as I can in Forth, within the limited domain of programming problems I have chosen for myself.

Outside that domain? I might even use C (and have actually) for certain problems. (Particularly ones where a team is needed, because it is so rare to find compatible thinking types who can handle the power of Forth to such advantage.)

A parallel: Out in my garage, I have a Lotus Europa. It weighs almost the same as a VW Bug of the same vintage. Both have one stearingwheel. Both have four wheels. Both have four cylinders. The engine is in the back in both. They even get comparable gas mileage. But the Lotus does straightaway speeds the Bug can only acheive in free fall, after driving off a cliff.

I happen to like the Bug (particularly the new one; my wife and I are considering buying one). But despite similarities, if I want to go fast, I would choose the Lotus. Now the Lotus has its own set of disadvantages. It is a bit harder to drive than the Bug. You don't see lots of them. Not everybody can handle it. Easier to make mistakes and have specatular accidents. But it was my everyday driver for about 6 years. The Bug is slower, bigger and perhaps safer.

Would you readily disagree if I said I got somewhere twice as fast in the Lotus as some guys in a Bug did? I might say, when I passed them they were failing the Bug for all they could get out of it. Would you argue I just said Bug drivers are clowns? or they couldn't get anywhere driving one? I hope not.

Same here. If you can't allow people to even express their personal experience and observations without saying they're bashing something... aren't you insisting on a revisonist history to fit your own biases? or protect your world view from the possibility there is another way of doing things, that might actually be faster or better?

I just wanted to make clear I am not arguing for the sake of arguing. It's not a "my sports team can beat your sports team" level of enthusiasm. If I can manage to "feed" myself for these many years, and could have chosen something else if I thought it were better, then there is more than casual commitment. I've made my money where my mouth is. I appreciate your trying to understand.

Let the flamers go. An intelligent discussion is the only thing worth reading on these news groups, and they rare enough to be pursued, and the wiffs of smoke are best ignored.

We can stop if you like. When I write in a news group, it is for the one I'm writing, and the many who read.

Yeah, it's cute. Everyone gets a poke in the ribs there, somehow connected to their foibles.

Random thoughts:

The only really bad languages that I have found are the human languages, as far as programming is concerned.

I still use PIC C from time to time, as well as Assembly on the PIC. I use the BasicX24 in some of my products, as well as Lisp, C++, in addition to FORTH.

Really, as I have stated before, as far as bad programming is concerned, LabView is the pitts. It copmpletely messes with my ability to type in code. If I didn't get so much suff done with it so quickly, I wouldn't use it. LabView projects include image processing, vibration analysis, motion control, engineering calculation. If I had to choose the worst language to teach programming style, it would be LabView. If I had to choose a language to teach programming concepts to programmeing hopefulls, it would be LabView.

I believe that FORTH didn't gain popularity, because it is so difficult to standardize something that is built to expand it's own lexicon. Every time you sit down at a FORTH console, you start build nifty little helper words to do ease things along. The problem is, sooner or later, there will be many people approaching the same tasks, and developing their own little helper words. Then when it comes time to decide to incorporate those helper words, everyone has a different idea how these things should behave. The problem is, it is part of the language to do these things.

In C, you have libraries, but they are just that, a library. They exist on their own, and are specific to a purpose, and in effect a platform in their core implementation. In FORTH, you are instantly changing your vocabulary when you define a new word in the dictionary. If you ever read Sci-Fi, you often come across futuristic lingo that the characters commonly use. You can't very well expect these words to come in to the common vernacular. Yes there are minor exceptions like "beam" as in "beam me up Scotty", but I, as an avid writer, cannot hope to get any words I make up, to be accepted by society, until after I win a Pulitzer Prize ;^) .

The thing is, the core of FORTH, is a low level language, just a hairs bredth away from Assembler. Then you add the specific words to standardize it, and you have a higher level language. When you are done with your task, it is a high level language.

So, lets assume a few things ( this is not meant to be a comparison to any language either actual of fictional, it is an enumeration. ) FORTH is interpreted at the command line( remember line numbered basic ? ) FORTH is compiled in it's execution. FORTH can be a powerful tool ( like a scalpel in the hands of a surgeon. ) FORTH can be a dangerous tool ( like a loaded weapon in the hands of a lower primate. ) FORTH is similar in implementation to Assembly language. FORTH is more human readable than Assembly. FORTH can be written to be very english like. FORTH can be an operating system, and a debugging environment. FORTH sometimes requires a concerted effort to develop in concert with other programmers. FORTH has a track record of high end applications. FORTH has general documentation available. FORTH has a standard. FORTH has free/inexpensive versions available for a wide variety of platforms from embedded microcontrollers to Lego, Palm Pilot, 68hc11, to the PC FORTH is modular in nature. FORTH implementations can be purchased for many thousands of dollars with lots of advanced features. FORTH for embedded systems allow the insertion of low level code into high level language.

See for yourself: Palm Pilot:

$69.95 + free eval $45.00 + free eval

Embedded

$39.00 for 8051 board with FORTH $99.00 for 56805 DSP + many more Free forth for the Pic

Windows

free

Lego

AVR The reason I like NMI' is that for $99.00, I get a dsp chip, with the language on board. Their series of modular boards are brilliant. I have used QUARTUS, WIN32 forth, and LMI FORTH as well, and they are also nifty.

I see nothing wrong here with using this as an embedded language, especially for robotics.

Professionally, I find myself working on projects with 1 to 5 year development cycles. These are often developed serially, since you can't really parallel develop a lot of these things, so when is my turn up at bat, I must be nimble.

Professionally, I must produce product that is robust. Being able to plug into an IsoPod, and evesdrop and orchestrate while things are running, is stuff out of the ICE age (pun intended)

Just my way of earning a living, and having fun. Opinions expressed are not necessarily those of anyone else, your mileage may vary. Intelligent, non demeaning, non libelous responses are welcome.

I wasn't sure if that was standard FORTH or not. I see that I implemented that in my "FORTH" interpreter as I wrote it around 12 or 13 years ago. Incidentally, I dusted it off and it compiled on my Unix box with no warnings or errors and works as expected.

Transfer of variables out usually does not happen in C. Even if some variables are passed in by reference, they are simply C pointers that are passed "by value" and are not treated as special with regard to function calls. I.e., when the function returns, no copying of values occurs - the stack pointer is usually just adjusted to throw away the passed in variables off the stack. If the function returns something, that is usually returned in a CPU register, if possible.

Yep. Normally used for constants, parameterized macros, etc.

It's interpretted - that can generally be an advantage to getting started quickly. "hello world" is the traditional first program in C or in a new toolset, new processor, etc. There's nothing special about the actual program, just that it should be simple, like blink an LED or something. It's purpose is to familiarize oneself with the toolset, by going through the process of creating an image and downloading that to the target system. But that's usually a one-time thing. After you learn to use the tools, you just don't think about it anymore.

I can see it's interactiveness being an advantage while debugging and trying things out, of course. But only a little more so than C, but I guess that would also depend on the efficiency of downloading code to the target environment. With my Atmel AVRs, typical time from making a program change (to add debug code for example) to having it running on the target is around 10 - 30 seconds or so depending on program size. I don't consider that to be terribly constraining.

But perhaps I'll explore this further by writing a FORTH interpretter for my AVR boards. I've already got one that I wrote many years ago, though my tendency would be to rewrite it since I didn't write my original one with a small architecture in mind. Just Googling a bit comes up with several available for the Atmel AVRs, so I'll have to consider whether writing or adapting my own is worth it or not. The nice thing about doing it yourself is you give yourself the freedom to add extensions. For example, I really like multithreading, and would want to include that facility. And I do enjoy implementing languages ... I've almost talked myself into it. Anyway, something for me to consider.

Regarding FORTH, it being highly interactive - do you sometimes find yourself making lots of changes directly on the target platform? Don't you run the risk of losing your work if you happen to zap a board or something before you get a chance to download the changes? I presume most FORTH based systems provide a way to download their contents after one of these sessions. Also, what about locking the code? Sometimes that's a concern if you do an application you might want to make sure someone else can't go in and change the code, or read out your code and make your work available to others without your permission. I'm sure most vendors address these issues in some way.

I try to be careful not to generalize on just a few data points. Projects fall behind for a myriad of reasons. Projects succeed for a myriad of reasons. 99% of the time it comes down to the people. Seems like successful projects follow certain individuals.

I have no idea of any details of the project in question, so it may be the developers skills or their personalities couldn't work well together, or it could be the management, or any host of problems with their development process. You say it is because they use C, yet I am not convinced.

I'd be real hard pressed to finger C as the problem unless the compiler / linker was so buggy that the developers spent most of their time tracking down compiler bugs instead of spending their time actually doing development. If that's the case, they should stay away from that C compiler vendor in the future. But again, not knowing any details, I have to say there is no way I can know. And, in general, I'm not one to blindly accept what someone else says, especially when my internal "suspicious statement alarm" is blaring. I don't have enough data to say what the problem with that project was, but Blueeyedrop did indicate that the problems tended to be more with ICE, compiler options, RAM/ROM/FLASH mappings, etc. This tends to lean in the direction that the developers aren't familiar with the tool environment or the chosen MCU processor, or perhaps the development tools are buggy. Perhaps they are working with a new processor and the tool set is not all that mature and has "issues."

Another possibility: was Blueeyedrop's solution complete? I find that the "core" of most applications is actually very simple and can be implemented in a short amount of time. But turning that into a production application ready to set onto the shelf of your favorite retail outlet is a whole other ball of wax. Perhaps Blueeyedrop wrote the "core", and not the polished app?

Or, it could be that Blueeyedrop is exceptional. One of the commonalities that seems to be recurring is that Blueeyedrop seems the one that can do in hours what most other programmers can't do in weeks or months. Maybe he is just one of those rare individuals that can code circles around most folks, and he just happens to make whatever tool he uses look really good. The fact that he has won Emmy's and has patented several inventions, tends to support that, anyway.

Or, it could be due to a combination of factors. Based on what I've heard, Blueeyedrop is obviously exceptional. And the state of the other toolset used is questionable. This raises doubt in my mind that the crux of the project's problems are because it was being programmed in C.

Nope.

Yes, sorry. Retracted. But that is the mental image I had. I've never seen "C'ers" flail. But I've seen inexperienced programmers flail, in just about any language or development environment they happen to be programming in at the time. That made me think of "clowning," but I shouldn't have implied that you actually said that. My bad.

It sounds to me like decision by committee, not a terribly efficient process. It's not at all surprising to me that 1 exceptional developer can run circles around 3 average. In fact, having the 3 together is a disadvantage! I'll take 1 exceptional any day of the week.

Were they contracted to do the work? After project completion, would they then be required to look for work elsewhere? Perhaps they were actually _motivated_ to drag the work out.

You see? You say it is because of C. I'm not convinced.

It's not? When we choose the words we do we imply certain meaning, even if we don't spell it out explicitly. When Blueeyedrop says that "I get really nauseous at work when I see the C'ers flailing about, and then I come along and crank out month long projects in days", there are lots of implied meanings there. A prominent one is the implication that C programmers can't get useful work done. Thus, that's just as good as Blueeyedrop saying "C programmers can't get useful work done", even though he didn't use those exact words.

With apologies to Blueeyedrop for me repeating that again since he has already recanted it twice. I didn't invent that as a "strawman", it was an implied meaning of the original post to which I responded.

And yet again, I only said that there could be another explanation, because I know for a fact that C programmers can be productive, that has been my experience. And Blueeyedrop did recant the statement.

But you keep saying - no no, it really is the fact that they are using C and not FORTH, even though Blueeyedrop has recanted the original statement, stating other reasons.

Cheers,

-Brian

There is one problem with writing a FORTH interpreter for AVRs, the lifespan of the FLASH ROM. Form what I can see AVR's can only be reflashed about

1000 times. While that seems like a lot, you could kill your ROM pretty quickly if you're not careful.

There is an AVR FORTH that uses a serial EEPROM to hold the user's dictionary. Sort of like a BASIC STAMP. I can't imagine that it's very fast however.

It's too bad. I think that AVR's architecture would make it pretty easy to write a FORTH kernal and the Mega chips have a healthy amount of SRAM for stacks and variables.

What is one "cell", 1 byte? 2? 4? 8? 16?

A lot more than a 3-byte JSR?

Transfer in and out of variables? Isn't this done before and after the "cell", as in, "A B + !C" of Forth,

in contrast to the C = Add(A, B) of HLL?

Seems to be the same overhead!

The setting and clearing of the stack frame (which may be optimised out anyway if compilation is all to registers), is part of the code of the CALLED routine and not part of the overhead of the caller. If you mean the tidying up of the stack, as opposed to the stack frame, this is done in C and is caused by the variable no of parameters that are possible. Not done in Pascal or other HLL.

Lab View, like FORTH, is dangled like a carrot in front of the programming ignoramuses of this world - the hardies. Whereas trivial sales programs can be demonstrated quickly (although I have thought it to be vaguely insulting to the intelligence of any hardy by inviting him to "wire-up" his circuit with a mouse); any program of any complexity very rapidly becomes unmaintainable because of topographical problems. HP's VEE is even worse, because what might be a simple block-structured IF statement in any other language, comprehensible with the merest of brief glances, becomes like the child's puxxle where you have to determine which fisherman has actually caught the fish!

C can be a powerful tool ( like a scalpel in the hands of a surgeon. ) C++ can be a powerful tool ( like a scalpel in the hands of a surgeon. ) Pascal can be a powerful tool ( like a scalpel in the hands of a surgeon. ) Delphi can be a powerful tool ( like a scalpel in the hands of a surgeon. ) Dartmouth Basic can be a powerful tool ( like a scalpel in the hands of a surgeon. ) Visual Basic can be a powerful tool ( like a scalpel in the hands of a surgeon. ) Assembly language can be a powerful tool ( like a scalpel in the hands of a surgeon. ) Machine code (Yup!) can be a powerful tool ( like a scalpel in the hands of a surgeon. ) Fortran can be a powerful tool ( like a scalpel in the hands of a surgeon. ) CORAL can be a powerful tool ( like a scalpel in the hands of a surgeon. ) PL/M can be a powerful tool ( like a scalpel in the hands of a surgeon. ) RTL/2 can be a powerful tool ( like a scalpel in the hands of a surgeon. ) Macro languages can be a powerful tool ( like a scalpel in the hands of a surgeon. ) ALGOL can be a powerful tool ( like a scalpel in the hands of a surgeon. ) COBOL can be a powerful tool ( like a scalpel in the hands of a surgeon. )

The obvious reasons?:

1) It would be difficult to hire 100 forth programmers, as they are harder to find (which, in fact, is a common reason why a language like FORTH doesn't get used - need for experienced practitioners) 2) You wouldn't need to employ 100 people if it was done in FORTH. Nor would it be a 9 month (or whatever) project.

Neither is a CS degree.

It would be equally misguided to put "softies" on the project who were not versed in hardware specifications, idiosyncracies, failure modes, basic physics, etc...

One of the beauties of FORTH is you can use it to create a problem-domain specific language and remove an "applications programmer" from even the knowledge or impression they are using FORTH. The same caliber experts who would create the unbreakable C-libraries or C++ classes would create the domain-language in FORTH. With far fewer people and less time, from most stories I've heard. I've *never* heard a story told where an equivalent application was build in FORTH, assembler, C, C++, Visual Basic that required less time and personnel by not using FORTH.

Rufus V. Smith Home Page:

Actually, back in the 70's, I used to write machne language code to play single note music on my 6800 machine. Memory was very tight back then. 1K (yes 1024 bytes!) of RAM was a deluxe machine and you had to be very economical in what you wrote. Plus who wanted to hex keypad bang in all that much code?

My father, on the other hand, used an 1802 processor and wote identical routines to play and share the same music. His total packages were always within 1% of the number of byte to write the code as my 6800 (known to be very efficient, well structured code and well structured architecture type of CPU). The 1802 packages where just as fast and included his JSR and RTS routines to achieve the packages.

Despite the preferred style of CPU the 1802 matched the 1MHz 6800 on every basis.

Hi Even in our heads we actually do the calculation in an RPN fashion as you've demonstrated. The need for the infixed notation has more to do with formula manipulation than executing the problem. We have to go through precedence rules to do the action of calculations. Forth is a more natural control language. Remember, you are not expecting the robot to manipulate a formula, you are trying to tell it what to do and when to do it. Mixing things up with formulas don't help one have a good feel for time or order. The original post mentioned issues with strings and floating point. I suspect the main issue was the particular Forth that was used. There are all kinds of ways to deal with such things that can be more natural. In most Forths, floating point has been dealt with by things like using F+ to mean + of floating point numbers. This is mostly the result that Forth is not a typed language ( as it is generally used ). This isn't to say it can't be or that one can't formulate other ways to deal with such things. One can make the interpreter more context sensitive and hide complexities. This has little to do with the issues of RPN. For debugging complex actions, I will take RPN any time. Action flow follows program flow. There are no tricks that can mess you up. The program does everything you tell it to do and in sequencial order. It does nothing more and nothing less unlike other clever languages. Dwight

whoot!!!

Hi What rules are you talking about. Forth is very simple. Program flow is consistant. The interpreter sees input. The input can be a number or a word. Words can be nouns, verbs, adverb or what ever. A word can even start another special interpreter to solve special problems. It is hard to break such simple rules. I don't know how one could. Dwight

A cell is whatever it takes to hold a system address. In 8 and 16-bit Forth's it's usually two bytes. BTW, the 16-bit model of Forth was exceeded about 10 years ago for systems which could take advantage of it. Our 332 Forth and IsoMax are 32-bit.

50% more, for a 3-byte JSR compared to a Forth 2-byte pointer.

If you coded to the point that everything was just a call in assembly language, then it would take 3 bytes. In Forth often coded to the point that everything is just a call, only 2 bytes. The Forth Instruction Pointer (IP) moves through these strings. There's a time penalty for the indirection through the thread, but a space savings.

Further, due to the pyramiding, the more you write in Forth the more compact the additional layers tend to become.

As far as set up and take down of variables, that only happens if you use variables. Then it is similar to C. But many times results of one call remain on stack for next call, so less overhead.

Is there something in the psychology of FORTH programmers that is not in the psychology of other softies that enables them to deal with many more function points on a daily basis? Hardly.

How does writing in FORTH bring about a more rapid analysis of the problem domain before committing to code? The answer is that it does not. FORTH is a hacking language where trivial applications may be coded without a great deal of thought. For _EXTREMELY_ complex applications the bulk of the effort is in the design, and the ultimate implementation language does not reduce the design effort required.

Agreed absolutely. I'd rather hire a graduate in a _REAL_ engineering discipline to do software; someone with a practical bent. CS graduates are just so much arrogant rubbish.

Rest snipped as too long and went off the bottom of the page.....

Well, apart the fact that the 4004 JSR stack has a maximum depth of three levels.

I would like to see a forth implemented with a 3-levels stack :-)

Ciao Francesco

"has"? "had"!

Perhaps you could do it by emulating "Push" and "Pop" routines for a larger stack, as the proponents of the Cosmac seem keen to do?!

Bwahahahahahahahaha!

Hi You need to think a little more about how you actually work math in your head and not how you read math on paper. You take the two numbers 4 and 3 and then apply the operation plus to it. I don't know how one could do it any differently. I was taught to read 3 + 4 as well but that isn't to say that I actually think this while doing the calculation. Maybe there is a major difference in the way people think about this problem. That might explain why for some, RPM seems so natural while for others it is like sliding on coarse sand paper. I use the 3 + 4 as a tool to do things like simplify formulas. When I see a formula, such as 5 * ( 4 + 3 ), I break it into a sequence of:

1. take 4 and 3 together with an add.
2. take 5 and the result and multiply.

I don't execute this as:

1. take find the result of 5 times some quantity to be determined.
2. the quantity to be determined is the result of 4 plus 3
3. complete step 1.

This is how it is read but not how I calculate it.

Maybe you were taught different. No wonder so many people have difficulty abstracting into different kinds of math relations. There is too much confusion between the execution and the manipulation tools. Arithmatic and math are two different things. I never expected them to be the same in my mind. Dwight

But the point is, who cares how we first learned to add, but rather how do we want to add numbers in tyhe advanced stages. This would imply that Forth programmers want everybody to stay in the elementary grade technique of thinking. Thus the language died.