Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ukma!tut.cis.ohio-state.edu!ucbvax!SCFVM.BITNET!ZMLEB
From: ZMLEB@SCFVM.BITNET (Lee Brotzman)
Newsgroups: comp.lang.forth
Subject: Re: History of Forth
Message-ID: <8912100714.AA07764@jade.berkeley.edu>
Date: 10 Dec 89 07:07:13 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 70


   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.