Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!hellgate.utah.edu!helios.ee.lbl.gov!ucsd!sdcc6!ir230
From: ir230@sdcc6.ucsd.edu (john wavrik)
Newsgroups: comp.lang.forth
Subject: Features
Message-ID: <7739@sdcc6.ucsd.edu>
Date: 23 Feb 90 03:12:34 GMT
Organization: University of California, San Diego
Lines: 125


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