Mitch.Bradley@ENG.SUN.COM (04/22/91)
Summary: ANS Forth did not cause the "evaporation" of the FIG model. It simply faced up to the reality that said model is already gone. > The ANSI document includes familiar words with altered meanings. The > words are there with the same name and (sometimes) the same semantics > -- but they can no longer be used to accomplish the same things. This is only true if your view of what is "Forth" is limited to a few implementations, e.g. FIG Forth and F83. If you include other popular implementations, such as Mach 2, JForth, F-PC, and numerous ROMable systems, then the meanings of those words have already been altered. For example, let's analyze the cited example, about "comma": > If you are a long time user of Forth, you probably have used comma in > many ways. You've used it to put data in the parameter field of an > object, you've used it to compile an address into a dictionary entry, > you've used it to store addresses or displacements for branches. In F-PC, "comma" cannot be used to compile an address into a dictionary entry (dictionary entries are compiled into a separate segment). Neither does comma work for this purpose on any of the native-code compiled systems, nor on most Forth chips. If FIG-Forth, "comma" works for branch offsets, but it is not necessarily portable, because some FIG-Forth implementations use absolute branch offsets and others use relative branch offsets (the author obviously knows this because he said "addresses OR displacements"). Many 32-bit Forth systems compile 16-bit branch offsets. Native compilers compile branch instructions. > You read the BASIS document *assuming* a meaning for comma. This is only true if either: a) You only know about a few relatively-ancient Forth implementations, or b) You simply choose to ignore the other ones > THE FACT IS THAT YOUR ASSUMPTIONS ARE WRONG. That's right. And ANS Forth DID NOT MAKE THEM WRONG. THEY WERE WRONG BEFORE THE ANS Forth EFFORT BEGAN. > Code that looks perfectly normal and runs perfectly > well on your system will not be portable: That's right. And it wasn't portable last year either. It will still run on your system, and on other systems sufficiently like your system, but not on existing or future systems that are implemented differently. ANS Forth can't wave a magic wand and make all old code portable. It can establish a set of usage restrictions that, if followed, will allow you to write new code that has an excellent chance of being portable. > --The word is the same > --The description is the same > --But the meaning (semantics in the true sense) > has been changed. The ANS descriptions are not the same. They include usage restrictions that are meant to help you understand what is portable and what is not. > To imply that a user of Forth will be able to make existing code compliant > by running it through a word processor or including a "prelude" is just > plain dishonest. Quite true. Fortunately, that has not been implied. The word-processor/ prelude thing is a specific technique that may be used to deal with certain spelling changes, such as the deprecation of the previously-ambiguous word NOT (NOT is now spelled either INVERT or 0= , depending on what you think NOT is supposed to mean). > certain things which could be done in a relatively straight-forward > way in traditional Forth systems may have to be drastically altered > (or possibly cannot be done at all) in the proposed ANSI Forth. The key is the word "traditional". In the past 6 years, many new Forth systems have been implemented, and have captured a very significant portion, perhaps a majority, of the total Forth market. Very few of these new systems conform strictly to the "traditional" FIG-style implementation model. Even polyFORTH, which is generally considered to be extremely "traditional" by most people, diverges significantly from the particular implementation model that most FIG/F83-bred hobbyists have in mind that allows "certain things to be done in a relatively straight-forward way". (e.g. polyFORTH vocabularies). > Most users of Forth are not readers of ForthNET. They will need to > rely on definition of the language in the Standards document. How many people learned Forth by relying solely on the Forth 83 document? Standards documents are not tutorials. > The ANSI project has been an unusual building project. The work has > been conducted from a builders' perspective -- decisions have been > made for the convenience of the builders. This is not at all unusual for a formal standard in the computer industry. Nor is it necessarily bad. If major vendors refuse to implement a standard, the value of the standard is severely reduced. The ANS Forth standard is better than most; the cost of participation was kept low enough so that "users" had some hope of participating (and many did participate). This is VERY unusual. Anybody who doesn't believe me is encouraged to join an IEEE standards committee. > It has its origin in a real short-term advantage (i.e. vendors don't > have to change existing products) Neither do those vendors' customers (e.g. users) have to severely rewrite their existing applications. Without a rewrite, those applications won't necessarily be portable (no amount of legislation could make that happen; the divergence has already occurred). However, those applications will still run, with minor tweaks, on their existing vendor's new ANS Forth system. The following statement is false: If my program runs on vendor A's ANS Forth Standard System, it will run on any vendor's ANS Forth Standard System. The following statement is intended to be true: If my program is written according to the rules for an ANS Forth Standard Program, then it will run on any Standard System. Not all programs are Standard Programs. In fact, most programs probably aren't Standard Programs. This is true for other languages as well; few languages that allow you to write portable programs force you to write portable programs. (Pascal tried to be strongly portable in this sense, and ended up being so restrictive that people eventually gave up and switched to C.) Mitch.Bradley@Eng.Sun.COM