Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!tut.cis.ohio-state.edu!ucbvax!MITCH.ENG.SUN.COM!wmb
From: wmb@MITCH.ENG.SUN.COM (Mitch Bradley)
Newsgroups: comp.lang.forth
Subject: BASIS feedback
Message-ID: <9007020306.AA02327@ucbvax.Berkeley.EDU>
Date: 29 Jun 90 17:03:24 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: Mitch Bradley <wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV>
Organization: The Internet
Lines: 74

I wish we could get out of this mode of squabbling over picky little
details.  How you spell various words (NOT vs INVERT, WORDSET vs VOCABULARY,
/ vs. whatever) is SMALL POTATOES.  I mean it just ISN'T WORTH COMPLAINING
ABOUT.

The big issue is, do we want Forth to die, or not?

If Forth stays the way it is, I guarantee that it is going to dwindle
away to obscurity.  United we stand, divided we fall.  We are currently
badly divided, and we are falling like a rock.

With the current Forth standard, it is not feasible to write very many
useful portable programs to operate in today's computing environments.
Proof: count the counterexamples (you can put one of your hands in your
pocket; you won't need it.)

Here is a realistic view of "current practice":

	There is a small core of words that people mostly agree upon.
	This core set, by itself, is barely sufficient to write toy
	programs, and hopelessly inadequate for anything "real".

	There are some additional concepts that people sort of agree
	on, (e.g. division, vocabularies and search order), but whose
	precise semantics differ WIDELY among extant Forth implementations.

	There are a bunch of things that EVERY COMMERCIALLY SUCCESSFUL
	Forth system has, but for which there has been no standardization
	(not counting the attempts of ANS Forth).  Those things exist
	because customers DEMAND (and I mean that in the strongest possible
	sense) them.  The obvious example is file system interfaces and
	memory allocation.

	Like it or not, a substantial percentage of the Forth community
	is not using Forth 83 (MacForth, MVP Forth, MMS Forth, FIG Forth).

The net result is that "current practice" is leading to the demise of Forth.
I can't write many useful programs in standard Forth, and I can't share
programs written in one of the various incompatible extended Forths.

ANS Forth is and attempt to correct this situation -

	a) By stating the "portable boundaries" of core words (i.e. the
	   range of usage over which the word is indeed portable).
	   "/" is a good example.

	b) By defining new "neutral" names for needed functions, in cases
	   where "common practice" has causeed the "common" names to be
	   hopelessly non-portable.  This was done in preference to
	   "just picking (e.g.) floored division or bitwise NOT" in an
 	   attempt to reunite the Forth-83 and Forth-79 camps.

	c) By adding EXTENSION packages to extend the utility of Forth
	   in directions that are needed by MANY users (but not all users;
 	   that's why they are extensions and not required words)

So, please let's stop bickering about trivia and let's start moving forward
as a team.  The ANS Forth BASIS may have some aesthetic problems (depending
on who you ask), but I firmly believe that the language defined therein
WORKS and furthermore, that it CAN BE IMPLEMENTED based on nearly all
existing Forth systems, with very little backwards compatibility cost in
terms of breaking existing code (i.e. you don't have to change the way
your system's NOT and / and VOCABULARY work; leave them in your system
without change).

And please, if you don't need a particular extension wordset, just ignore
it, okay?  Don't yell and scream about its existence, because there are
a lot of us out here who very much need files and memory allocation and
controllable error handling and floating point.

Forth is a tool, not a Holy Grail.  Utility of tools is greatly enhanced
by standardization, and standardization involves compromise.

Mitch