ir230@sdcc6.ucsd.edu (john wavrik) (02/23/90)
Mitch Bradley writes:
# The problem is not that I cannot write whatever string package I want.
# The problem is that I should not HAVE to.
People who use Forth simply do not live in the spartan environment that
Mitch Bradley portrays. It's a bit unfair to look at a sparse public
domain system and use this to characterize Forth.
Commercial Forth systems have offered many features for years. I used
Miller Microcomputer Systems MMS-Forth for a long time. Not only did it
have a good screen editor for blocks, but offered windows and macro keys,
and add-on packages for arrays, strings, random numbers, long-address
(for IBM), graphic, clock utilities, debugging packages, sounds, floating
point, extended precision integers, a cross reference utility, a utility
to transfer files to DOS (stand-alone version). A good word-processor,
database system, and communications program were available (with source
code) at extra cost.
This is not an advertisement for MMS. I think it fair to say that a
similar list could be made for other commercial versions of Forth. I no
longer use MMS-Forth -- but up to the point where I wanted to show my
work to others and use it to teach Forth to students, I was quite
satisfied with it. [The problem is the "one person on one machine"
licensing agreement not the quality of the software.]
# Lots of people reject Forth
# because it forces them to reinvent wheels, when they would prefer to
# build upon other's work, adding value in their own domain of expertise
# instead of building this basic library and that basic library.
Exactly. And in order to build on other people's work, a language must
be powerful and portable -- it must be possible for you to write
significant things in one implementation of Forth which will run on
any other implementation of Forth.
This was one of the primary reasons I selected Forth for my work 10
years ago. At the time it was probably the most portable language in
existence. Since it is built on a small simple core and allows
language features themselves to be added and modified, it seemed
destined to retain both its power and portability for a long time.
I guess the reasons given for rejecting Forth depends on who you talk to.
One of the main reasons I've been given is that, after fig-Forth, the
Forth community chose a direction which led to a decrease in portability.
"It's too complex and not portable" or "These days, if you want to do
anything significant in Forth you have to throw portability out the
window."
Our main priority right now should not be to add features, but to
restore portability. If vendor XYZ adds a string package to Forth, you
only have XYZ-Forth with a string package. No guarantee that applications
on the level of language features can be written portably.
# One could claim that one could simply select a string package that
# somebody else has written. True, one could, if one happened to
# know about its existence and if one knew where to get a copy and
# if one trusted the quality of that package. Of course, then you
# would probably have to spend some money documenting the package
# and training your personnel about it.
I have something in mind like the Fortran IMSL library of subroutines
for mathematics. Part of the persistence and appeal of Fortran is the
existence of such libraries. Subroutines can be selected appropriate to a
particular problem and incorporated into a programmer's code. There is no
Procrusian bed -- one can select whatever is most appropriate.
# If there is a standard package, then one can assume that competent
# programmers know about it and that every worthwhile vendor implements
# it and supports it, and you can depend on market pressure to ensure
# its quality.
Again this assumes that (1) there is one "best" way of implementing a
language feature and (2) everyone wants it in their system. With
conventional languages we don't have much choice -- conventional
languages are rigid: features must be built in to the language by the
implementors. It would be silly to build this rigidity into Forth.
I suspect that we are going about producing Standards in a way
inappropriate to Forth.
(1) Forth has a small core which should be completely
standardized and fixed -- a great deal of attention should
be spent insuring that the core is powerful enough to accept
language features as portable add-ons. If "hooks" need to be
added for potential features, these should be specified. If
this means words need to be deferred, the mechanism for
deferring words should be specified. etc.
(2) Certain features, like hardware floating point packages,
and graphics will most likely be supplied by the vendor as
options. These should be as rudimentary as possible to allow
portability of a variety of extensions.
(3) Guidelines for variants of other desirable features might
be offered -- several levels of string packages, several
types of storage management schemes, etc. It is to be
expected that these can be written to run on any Forth
system and added by users.
I hope this is what is now happening with the ANSI effort. Some people
seem to think it isn't -- that much of the core is being made
"implementation dependent" and that effort is going into selecting ONE
particular way of dealing with each of several desired extensions -- and
putting them in category 2. The end result, of course, will be to make
Forth less portable and, therefore, to make most extended language
features vendor-supplied items -- it would supply common features in a
proprietary way at the expense of the overall power of the language.
A language which can allow users control over language features is
unique. Ultimately, an effort to make Forth "commercially viable" by
removing its unique characteristics will be found counterproductive. The
world really does not need another fat rigid language.
More than features, I want the ability to build features portably.
--John
John J Wavrik
jjwavrik@ucsd.edu Dept of Math C-012
Univ of Calif - San Diego
La Jolla, CA 92093