response to tk:

Forth

It is probably the nature of Forth and also the excelent design of colorForth that I don't worry about standards and compatability so much. For other things, like Unix, as you say the cost may be huge.

In Forth the main thing that can foul things up is the semantics of the operators. As I've pointed out previously, the operators of colorForth are quite evolved. The block format is unlikely to change, it was designed to be extensible, so embeding different types of information in source code is entirely possible. I think this idea is quite neat, you could embed a string from another character encoding, or any other custom data. You could even include the code which extends the compiler inside your application, so there is no dependency.

So short term anoyances are unlikely with colorForth. In the long term, if the system has really changed so much, it is likely the hardware has changed as well. In this case your code probably isn't relevant. It might be best to start from scratch. I've noticed the changes in Chuck's Forth occur with changes in the hardware. The last 30 years have seen many hardware changes. Forth is considered the interface to the machine, so it is quite understandable for the Forth to change as well.

Portability

colorForth ignores portability with the result of extreme simplicity. Things are generally easier to write ignoring portability. This comes at the cost of the effort to port the code to different platforms. If the number of platforms is small, the cost is also small. Unix/C in constrast has a gigantic portability apperatus. The C language has complex type system, this probably helps portabillity to a degree, but does not really make C much more portable then macro-less colorForth. To accomidate for C's pitfalls there is also build systems, conditional compilation, and portability layers, more complexity. Furthermore, there is software compatability. C programs are often made compatible with multiple versions of Unix and sometimes Windows, even more complexity. The result is clear. Unix/C programs trade a great amount of simplicity for software/hardware compatability. Now the question is, which way is a greater burden on the programmers? From my experience it has been Unix/C way. Most code I don't even bother looking at, the cost of changing it is much greater than the benifit. On the other hand colorForth has not yet aquired what I consider basic functionality (networking, web, email). It will be intersting to see how well the colorForth method scales. I have a good amount of confidence in it at least.

Executing tree structures

On the pentium, I don't know how good that techinique would work. I'm quite wary of branches on the pentium in my own code. I had an oportunity to use this techinique recently, building a tree structure to decode a huffman coded stream. I decided not to. Jeff Fox used this techinique on a stack machine with good results, and aparently Phil Koopman did too, from the description in his book. When I get around to it, I'd like to read his thesis, which deals with the same subject.