ZMLEB@SCFVM.BITNET (Lee Brotzman) (12/10/89)
This topic seems to be getting farther and farther afield, so I'll reply this one last time, especially to correct John's spelling of my name: the name is Lee, L-E-E, which is not an abbreviation of "Leo", "Leroy", "Leland" or any other name. John Wavrik writes: >As it turns out, Forth-79 differed from FIG-Forth in only a few words: > > WORD -- in FIG it did not leave an address (but the address > was the end of the dictionary) > <BUILDS -- replaced by CREATE > VARIABLE -- required an initial value in FIG-Forth > NUMBER -- I no longer remember the precise difference > >At any rate, I made VAX-Forth look like a Forth-79 with a few screens of >adaptation (several years later Martin Tracy was to call this a "prelude"). > >WHILE BROTZMAN MAY TECHNICALLY CLAIM THAT FIG-FORTH DISAPPEARED AT THIS POINT, >IT WOULD BE MORE ACCURATE TO SAY THAT IT BECAME THE FORTH-79 STANDARD. It would also be technically correct to say that Forth-79 became Forth-83. From the user's viewpoint, modifications from Forth-79 to Forth-83 can also be implemented in a few screens. I will grant that making application code compliant between FIG and '79 is easier than between '79 and '83. From an implementer's point of view, each incarnation of a standard, from the informal FIG model to '79 to '83 entailed a cost to modify the standard words and also all the system code that is built from those words. For instance, <BUILDS wasn't simply replaced by the word name CREATE, there were subtle changes to the implementation at the system level; any word that used WORD had to be modified to conform to the new stack effect; changing DO-LOOP runtime code was necessary. The change from '79 to '83 was expensive for system-level and user-level programmers (usually there isn't any distinction between the two, but I'm trying to separate kernel-level programming from application-level). It would be counter-productive to slide backwards and reinstate an older model or create a completely new one. That is why the ANSI Technical Committee is using the Forth-83 standard as its basis and is making every attempt to keep existing code compatible with ANS Forth. Although the '83 Standards Team may have been mistaken to change the underlying structure of the language, that doesn't justify repeating the mistake. I agree that FIG Forth was very portable and had a great many implementations. As Tom Almy stated, there was plenty of room for add-on features. Of course, as soon as you use a new, non-standard feature, portability takes a hit. The greatest portability problem in Forth is NOT from selection of one internal architecture or another, but rather from additional features in a particular implementation over and above the standard. Simply setting the internal design in concrete will not solve this problem because it stems from the very nature of the Forth language. Forth is too malleable to ever be completely portable, unless all programmers choose to start every project from the bare standard word set (or even then). Forth has a twenty year history. For 30% of that lifetime Forth-83 has been the standard. Soon ANS Forth will take over where Forth-83 leaves off, including standardized wordsets for previously nonstandard features like stack cell widths other than 16-bits, addressable memory other than 64K (while at the same time defining standard means for ensuring portability between systems with varied architecture), floating point math and host operating system file I/O. The cost of compliance should be relatively low. Portability between systems will be enhanced. Is this perfect? No. Is it better than throwing out whole classes of Forth implementations and embracing a single architecture created in the past? Definitely. Will something better be created in the future? Bet on it. -- Lee Brotzman (FIGI-L Moderator) -- BITNET: ZMLEB@SCFVM -- Internet: zmleb@scfvm.gsfc.nasa.gov -- The government and my company don't know what I'm saying. -- Let's keep it that way.