I was introduced to Forth in 1988 or 89 through the Forth module on my Hewlett-Packard HP-71 hand-held computer which had basically Forth-79 but a little strange because of its 4-bit data bus and 20-bit address bus. Bytes were of course two nybbles, but a cell was two and a half bytes, five nybbles, so a complete address would fit in a cell. It's strange, but did not present any problems. The BASIC in that computer was by far the best BASIC I've ever seen (when you include the Math module and user group language extensions), but the Forth implementation was very poor. I was able to dramatically speed up many words just by re-writing them even as secondaries, not resorting to assembly language for its even stranger Saturn processor with 64-bit registers. I never did learn its assembler.
Then I went to Forth-83 for the 6502-controlled test equipment at my last place of work about 1990. It seemed considerably better. Forth was popular and apparently making big strides in acceptance and standardization in that time period, and it showed in the difference between the two standards ('79 and '83), it seemed to me. (Fig-Forth was before Forth-79.) ANS Forth came later after much debate of the X3J14 committee; but although it has some good things, there are also various things I don't like about it, so I'm glad I don't have to be locked entirely into one standard or another.
There are of course many words in common usage that are not part of any official standard; so when I found that various words I wrote were in common usage but had different names, I changed my names to match common usage. One example is RANGE , which tells if n1 is in the range of n2 to n3, which of course I used a lot in the automated production test equipment, to see if a test result was within acceptable limits. I found that others did the same thing and called it BETWEEN , and that it almost made it into ANS Forth under that name; so I changed the name of mine to match. So in a way, common usage itself becomes a standard.
There are some parts of ANS Forth that present extra overhead in order to make it more portable across a wide range of processors. My personal opinion is that they may have taken this a little too far. At some point, we need to acknowledge that no language that lets you get so close to the heart of the computer will be 100% portable. We must consider the programmer(s) and platform(s) involved, and decide on a good balance between portability and optimization. I personally prefer a little more optimization at the expense of some portability. Greater optimization means a particular processor can be used for a wider range of jobs anyway, which would in itself reduce the need for portability.
Jack Woehr of Vesta Technology who was on the X3J14 committee says in his book "Forth: The New Model", "When Forth, which some hold to be inextricably wedded to hardware, takes responsibility for cross-platform portability, a certain light-footedness and grace will be surrendered." He admits that optimum portability and optimum efficiency don't come at the same point. Fortunately he also says it's not the committee's intention to
force anyone to comply with the standard. What I have is basically Forth-83 with a lot of extensions from my own experience, the books "Starting Forth" and "Thinking Forth," Forth Dimensions magazine, ANS, and common usage.
Edit: Jeff Fox has a great article entitled "ANSI Forth is ANTI Forth" at
http://www.ultratechnology.com/antiansi.htm, and Chuck Moore, the inventor of Forth agrees. See why.
Changing the subject-- I worked with screens very little, and found them extremely limiting, with too many disadvantages to justify keeping them for their few advantages. I have mostly used text files for my source code, with a full-featured programmer's text editor (MultiEdit, for DOS in my case) which I've had as many as 32 files open at once on. The computers I've run the Forth on had very little in the way of human I/O, so I have been using the PC (with its full keyboard, hi-res monitor, and disc drives) to write and save the source code, and send that to the target for on-the-fly compilation, assembly, or execution, as appropriate, when needed. Turn-around time for writing and testing a little piece of code is instant, without having to exit or suspend or background the editor or re-compile the whole application. The text editor was not only convenient for the obvious reasons, but also allows marking any size of block down to as little as single "." and sending that out as if printing it (but it doesn't have to know that the target computer is not a printer). For the automated test equipment, I would get things going this way and periodically add the newly developed material to EPROM. When finished, the whole application was in EPROM, so it was no longer dependent on the PC.
It would slow it down a lot if it had to keep checking those things needlessly during program running.
. In my listing I changed it to [SSIZE+4]*NBUF since I use [] in lieu of () in my expressions.