steve@kontron.UUCP (Steve McIntosh) (04/27/85)
---
Rebroadcast with permission
---
Report of the
FORTH Non-Standards Team
One FORTH to rule them all, One FORTH to find them, One FORTH to
bring them all and in the darkness bind them. In the Land of
Mordor where the Standards lie.
--- J. R. R. Token,
The Lord of the Ring Buffers
Abstract:
The Forth Standards have lead to additional confusion
and a plethora of versions of FORTH on the market.
They have failed their primary purpose, and should be
dispensed with. The author compares the workings of
the Standards team with the original evolution of
FORTH. The origins of two "platypus" FORTHS are
described.
Charles Curley
5595 E. 7th St. #285
Long Beach CA 90804
213/432-0144
30 May, 1984
Being an inquiry into Meta Standards as applied to FORTH.
About the FNST
The FORTH Non-Standards Team (FNST) is a self-appointed body
of self-proclaimed expertness, membership in which may be
conferred by the whim of its founder and sole member, Charles
Curley. In other words, it has all the authority of any other
body of experts, e.g. the FORTH Standards Team (FST), the FORTH
Interest Group (fig) or the Department of Defense (Yeech). I.e.
moral persuasion. Unlike other such bodies of expertness, the
FNST admits and indeed revels in its total lack of authority.
Unlike the FST, the FNST has only one member. Unanimity is
therefore easier to achieved. Indeed, the FNST is proud of its sole
membership status, since it was a similar "committee of one",
Chuck Moore , which originally gave us FORTH. Other examples
include Galileo Galilei and Sam Adams. In contrast, the 1979 and
1983 FORTH Standards are products of committees, and they show
it. Similar committees have given us COBOL, ADA, the Inquisition
and the Internal Revenue Code.
Abstract
The purpose of this Report is to inquire whether the
original stated goal of the 1979 and 1983 Standards has been or
is likely to be met, and, if so, whether it has been worth it.
The goal is that of transportability.
"The purpose of this FORTH Standard is to allow
transportability of Standard FORTH programs in
source form among Standard FORTH systems. A
Standard program shall execute equivalently on all
Standard FORTH systems."
-- 1979 Standard
History
Previous to the existence of the FST, the way a new FORTH
dialect was defined was that one or two people would sit down and
say, we need a FORTH to do THIS, where THIS was the project at
hand. As the project evolved, so did the FORTH. Changes were
evolutionary, with minimal discontinuity. As more and more
projects were completed, wisdom in what to add or change also
grew. Indeed, for a FORTH programmer to have the source for his
version of FORTH was the rule, not the exception. The first FORTH
programmer, i.e. Chuck Moore, had his source.
As soon as the number of FORTH programmers began to
proliferate, the number of FORTHs also began to proliferate. "in
the Beginning, there was Chuck Moore's file... And mini-FORTH
begat micro-FORTH...." etc.
Then along came the FST. They looked upon the void and
decided that they should bring order out of chaos. This feat they
attempted by trying to define a single FORTH which, so theory
went, everyone would adopt, and then we'd all have the same
FORTH, and my programs would run on your system, even though we'd
never met, and I hadn't the foggiest idea what computer you were
using. Remember that goal? It's called "Transportability." You
know, like ADA. Microsoft BASIC. The San Diego freeway.
So the FST came up with what they called the 1979 Standard,
even though it was published in October of 1980. Oh, well, next
time! Anyway the 79 Standard was cast in concrete, dipped
inliquid helium and glued to the side of the space shuttle. It
was, we were told, a SOLID definition of a programming
environment called FORTH.
Ambiguity of Standards
There were several problems. First, it wasn't solid at all.
Close examination revealed enough ambiguity that the Standard was
proven to be about as solid as a marshmallow. And didn't taste as
good. The ambiguities have lead to serious problems in
transportability.
platypusFORTH
Second, the early days of the FST gave rise to a number of
'platypus' 79 Standard implementations. Rockwell International's
AIM 64 FORTH is an excellent FORTH implementation, but has
serious transportability problems. It was developed during the
time that the 79 Standard was being worked out, from the fig
model. The result was a curoius blend of the two. In general, the
names tend to reflect the 79 Standard, but the definitions and
workings the fig model.
This could be ignored as an aberration except for the fact
that the Rockwell FORTH may well be the largest shipped FORTH
implementation in the world. If not, the Rockwell R65F11 FORTH is
produced in the several tens of thousands quantity range.
Another embarassment is the history of what has become known
informally as leoFORTH, named for Leo Brodie, author of Starting
FORTH, and former employee of FORTH, Inc. Mr. Brodie wrote an
excellent introduction to FORTH. This is in part due to the fact
that he is an excellent writer, and in part due to the fact that
he himself had just been introduced to FORTH, and indeed to
programming in general.
Starting FORTH was also written just after the 1979 Standard
had been finalised, so that Brodie faced a problem similar to
that faced by the Rockwell implementors. Except that the problem
was worse.
Brodie was at that time a paid employee of FORTH, Inc., and
had been hired by the company to write the book. The book was
intended to be an improvement over their then current
documentation for polyFORTH, Using FORTH. So three things were
going on simultaneously at FORTH, Inc. One, the software wizards
at FORTH, Inc. were trying to puzzle out the 1979 Standard. Two,
they were also trying to decide how much, if any, of the Standard
they would adopt into polyFORTH. Three, Brodie was trying to
write a book describing the results of One and Two.
In other words, Brodie was trying to describe a figment of
two seperate comittees' imaginations. One might refer to the
result as "polyglotFORTH".
Starting FORTH has sold over 80,000 copies, which is far
more than the number of people who will read this report. This
means that there are thousands of people out there who will never
get any explanation why it is that the code they type in to their
alleged 79 Standard systems, suitably modified in accordance with
the footnotes, doesn't compile, or doesn't run correctly if it
does compile.
Secret Weapons
One of the better kept secrets of the FORTH community is that
ther is an editor, suitable for use with Starting FORTH.
This is a public domain editor, written by Sam Daniel. Indeed,
the only better kept secret is how Rockwell's target compiler
works. This means that one whole chapter of the book -- unless
one is privy to the secret -- is at best merely useless and at
worst highly confusing.
But one learns of the existance of the leoFORTH editor only
by being a member of the FORTH community and privy to its
secrets. Such a person a) probably has his or her own editor and
likes it better, and b) doesn't need the leoFORTH editor because
he or she dosen't need to read Starting FORTH. Catch 22.
Effects of Standards on Vendors
From the point of view of a system programmer trying to
maintain a "current" system, the FST has had a less than ideal
effect. Previously, changes were evolutionary, and a programmer
could adopt the individual changes as needed, according to his
situation. The effect of the FST is a massive discontinuity every
four years, and one finds oneself either madly scrambling to
catch up, or consciously abandoning the goal of currency.
Furthermore, in the commercial world, introduction of the
given standard causes a similar mad scramble among vendors to be
the first kid on their block with the new Standard. While speed
of implementation and excellence are not mutually exclusive, they
are also not mutually conducive. The result may be that a vendor
will achieve commercial success by being first with a mediocre
implementation, while the excellent implementation takes longer
and is therefor ignored in the marketplace.
Advertising copy being what it is, one may be led to the
impression that the implementors of the latest Standard have
found the holy grail, the cure for cancer and the perfect martini
all rolled into one, when in fact (as we have seen) they may be
marketing yet another mediocre product. Besides, weren't they
proud of their implementations of the last Standard?
The resemblance of the FORTH vendors to the American
automobile manufacturers, with their annual "model years" or the
American television broadcasting networks is rather more than
superficial. All of these groups have an obvious short term
market incentive to encourage planned obolesence and fads.
De Facto Standards
If a particular version of FORTH commands a large enough
segment of the market, one may claim that it is a 'de facto'
Standard, just as the IBM PC is a 'de facto' Standard computer,
and its operating system, MS-DOS, has become a 'de facto'
Standard operating system.
The FNST is of the opinion that leoFORTH, polyFORTH Rockwell
FORTH and MMS FORTH are all de facto Standards, albeit of varing
ambiguities.
In any case, the FNST suggests that there has been a greater
proliferation of Standards since the FST first met. This means
that the FORTH community is now further away from the goal of
transportability than it was when the FST was first created. To
be fair, it should be pointed out that the stated purpose of the
two Standards was transportability among Standard systems, not
all systems.
False Compatability
This brings us to the third problem with the 79 and 83
Standards as far as transportability is concerned. That is the
vast undergrowth of vendors who call their product "Standard"
when they are not compatible, and in fact are noticably non-
Standard.
These incompatibilities are not mere quibbles of
interpretation (which are bad enough, as mentioned above), but
gross violation of a given Standard. A glaring example is an
implementation which claims to be 79 Standard, but which requires
an initial value for the defining word VARIABLE.
One may note the frustration of N. Solntseff, writing in D.
Dobbs for September, 1983 (p. 83):
"Of the half-dozen versions of FORTH for OSI and
Commodore 64 computers I have acquired, all
claiming full compatibility with the Fig-Forth 79
Standard, (sic) NONE are 100% consistent with the
latter." (emphasis in original)
Solntseff's complaint is unusual only in that it is in
print.
Standards are Voluntary
Unfortunately for the cause of transportability, the FST has
no means of enforcing its decrees on the vendors, which,
fortunately, may be due to the fact that, like the Women's
Christian Temperance Union, the FST has no way to make adoption
mandatory. It cannot reach for a loaded legislator. This means,
however, that there will continue to be a blundering herd of
FORTH implementations out there which claim to be 79 or 83
Standard, but which in fact are not.
Recommendations
The only thing that the FORTH community can say to the
potential buyer or a system is 'caveat emptor.' We don't need a
FST to do that!
In light of the above discussion, it seems that there is
nothing to be gained from further activity of the FST. Indeed,
past experience indicates that release of a 87 Standard, should
such a thing come to pass, would only add yet more confusion to
an already bubbling caldron. In fact, the FNST would like to see
the proposed 87 Standard 86ed.wls@astrovax.UUCP (William L. Sebok) (05/08/85)
Amen. A thing not mentioned there was an earlier, I believe, less official
attempt at standardization in 1977. I started programming in Forth around
1976. I had just finished getting all of my software converted to the 1977
style Forth when the 1979 standards came along. I had just finished converting
to the 1979 standards when the 1983 standards came along. I haven't even
had the stomach to try to convert to the 1983 standards. I look forward to
1987 with dread. These constant incompatible changes in the basic structure
of the language play havoc with any attempt to maintain any large base of
existing software written in that language.
--
Bill Sebok Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wlskeithd@cadovax.UUCP (Keith Doyle) (05/11/85)
[...............] >Amen. A thing not mentioned there was an earlier, I believe, less official >attempt at standardization in 1977. I started programming in Forth around >1976. I had just finished getting all of my software converted to the 1977 >style Forth when the 1979 standards came along. I had just finished converting >to the 1979 standards when the 1983 standards came along. I haven't even >had the stomach to try to convert to the 1983 standards. I look forward to >1987 with dread. These constant incompatible changes in the basic structure >of the language play havoc with any attempt to maintain any large base of >existing software written in that language. >-- >Bill Sebok Princeton University, Astrophysics I agree. Me? I started with a Forth-79/Starting Forth hybrid, and later decided to convert completely to FIG-Forth. FIG-Forth is the easiest and cheapest to get hold of, most public domain is FIG, and so far, I've seen no reason good enough to change. I've got 4 different systems at home, and two at work, and as much as I like the LMI Forth, there's no way I'm going to buy 83 (or whatever) versions for all 6 of these systems, especially if there is something available public domain. Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd