ir230@sdcc6.ucsd.edu (john wavrik) (12/04/90)
WHAT MAKES FORTH FORTH?
This question was raised in an informal discussion among several
participants (including Charles Moore) at the recent FORML
Conference at Asilomar. It seems like a good topic to pose for
discussion in this newsgroup. Perhaps if we can understand the
qualities that account for the strength of the language we will
be able to understand what we must fight to preserve -- and what
we can safely give up in the name of "progress".
The discussion at FORML seemed to be directed at identifying a
single feature of Forth responsible for its properties (is it the
use of indirect threaded code? the use of stacks? Reverse Polish
syntax?). No one seemed able to pin down any one property that
accounts for the subjective experience of "Forthness". Perhaps
what makes Forth Forth is a combination of these factors -- or
perhaps these properties are just symptoms (they appear because
of what makes Forth Forth -- but are 0= the cause).
I use Forth for work in parts of mathematics requiring
experimentation with data representation and algorithms. In my
field the program is the data -- so language performance is
measured in terms of the ability to quickly write and modify
programs, 0= merely in terms of execution speed. There is no
doubt that Forth is a high performance language in this sense.
Let me contribute an idea -- hoping that others will come up with
more ideas. My present contribution comes from an inspiration for
modifying an application I had discussed at the conference. What
makes Forth Forth (among other things) is that it allows one to
choose the right names for things -- in which I include the
ability to control syntax and data representation.
The application in question concerns group theory -- I am
revising it to provide (together with support material) an
introduction to Forth for mathematicians. The aim is 0= to
provide them with everything they might want to know -- but
rather with a good set of (Forth-based) tools for computing it.
A group is a set. It has elements and a binary operation. It also
has sub-objects of interest (called subgroups). As I used the
first draft of this application in my class this year, I found
myself often needing a list or count of those subgroups of a
group which have additional properties -- i.e. looping through a
list of subgroups. In the original application I had a word SHOW-
SUBGROUPS which looped through the subgroups and printed them.
Every time I needed a loop, I found myself returning to SHOW-
SUBGROUPS to remember the exact syntax for initializing the loop.
: SHOW-SUBGROUPS SUBGLIST >LST SGPTR @ 1+ 0
DO CR I 3 .R 2 SPACES
I LST@ 'SUBG @ SG.
LOOP ;
There is a logic to this definition which becomes apparent if you
realize that the subgroups are stored in an ordered list as they
are generated -- and that the address where the subgroup is to be
stored is needed in the generation process. All of this, however,
should be irrelevant if all you want to do is run through the
subgroups (already generated). It is very easy to forget exactly
how the subgroup list is installed as the current ordered list,
how to determine the loop limits, and how the address of the
subgroup is named. The insight was to introduce "the right
names":
: FOR-ALL-SUBGROUPS SUBGLIST >LST SGPTR @ 1+ 0 ;
: SUBGROUP LST@ 'SUBG @ ;
The above definition becomes:
: SHOW-SUBGROUPS
FOR-ALL-SUBGROUPS DO CR I 3 .R 2 SPACES
I SUBGROUP SG.
LOOP ;
Similarly the loop limits for a loop over all possible groups are
now generated by FOR-ALL-GROUPS and loop limits for a loop over
all possible elements of the current group are generated by FOR-
ALL-ELEMENTS. Three types of loops (each with context-dependent
limits) can now be included in definitions without looking up
earlier code -- their names make it obvious how they are used.
The same application provides an example of "the right names" in
the sense of the proper data structures. The data for this
application is a set of multiplication tables for 48 groups each
having at most 16 elements labelled A,B,... . The obvious
representation for this data is a 48 x 16 x 16 array of
characters. Many languages force on us a means of expression
derived from this representation and a relatively sparse set of
data-structuring tools:
X := Prod(25,'A','B')
would make X the product of elements A and B in group number 25.
This ignores the fact that, for this application, the group in
which the operation takes place is relatively fixed -- and that
we usually express the product as a multiplication of two
elements (rather than in functional form). Forth allows the group
number to be set as a global variable and group multiplication to
be expressed as:
<ele1> <ele2> G*
The elements can be treated as normal stack elements (they can be
SWAPed, DUPped, etc. -- and printed with an .ELE printing
operator). The result of the operation G* is put on the stack and
can be used in chain operations, stored, or printed. In other
words, groups and their elements can be introduced into a Forth
system and treated just like pre-existing Forth objects. This
consistency of new objects with old makes it possible to write
programs involving groups with the same facility as any other
programs -- their representation is transparent. We can call them
by "the right name".
Programming is an activity in which expressions in one world
eventually controls what happens in a0=her world. The closer the
means of expression afforded by the programming language can be
brought to the target the easier it is to write correct programs.
Conversely, the use of improper words can be distracting and
inhibit communication. By allowing customization of the
programming language, Forth is capable of bringing the computer
language closer to the target domain. This accounts for a great
deal of its power in "non-standard" situations.
To say that Forth allows one to use the correct names for things
begs the question. This property of Forth is the result of
several attributes -- among which are simplicity and access to
the implementation. To understand this, we must look at why
conventional postponed languages do 0= provide the same
flexibility. The postponer for a conventional language is large
and complex -- so modifying the language (in the sense of
modifying the postponer) is 0= a way in which a user is expected
to interact with the language. Instead the language designers
build in a host of features -- hoping to anticipate what users
will want to do. This is the cornucopia approach to programming.
Conventional languages tend to do quite well for users who do
what the designers anticipated. The fact is, however, that the
postponer is rigid. The only way to provide a viable alternative
is to allow the user access to the postponer -- and make
modification of the language (at the level enjoyed by the
designers) a feature of its use. This is the toolshop approach
to programming. Access alone is 0= enough -- for a user to
capitalize on his access, the postponer must be simple.
One may argue, then, that what makes Forth Forth is a design
based on a simple and accessible postponer. Features like the use
of a stack, Reverse Polish 0=ation, etc. can all be seen as
examples of the way this simplicity is realized. They do 0=
cause the simplicity or accessibility.
It should 0= be assumed, by the way, that a language with a
simple and accessible postponer must lack features. If the
postponer is simple, it is easier to make the language portable.
If the language is portable it is easy to provide features for a
broad market. If features are provided for a broad market, it is
easier to find those which do what you want -- or can be
modified. The main difference is that features are added-on
(options) rather than built-in to the language.
John J Wavrik
jjwavrik@ucsd.edu Dept of Math C-012
Univ of Calif - San Diego
La Jolla, CA 92093 RAYBRO%HOLON@UTRCGW.UTC.COM ("William R Brohinsky", ay) (12/04/90)
I define forth in terms of extensibility: If I can reach down into the bowels of the machine and create words that simulataneously touch the lowest levels and the highest levels of the software, that's what makes it for me. The matter of reverse polish notation is a convenience. Stacks work best with RPN, and this can be removed, if an annoyance, by extending the FORTH to accept and parse algebraic notation. Stacks themselves can be avoided: note the proliferation of Nth generation forths that support locals. Indirect threaded code doesn't make it, either: of the three forths for the AMIGA that I've seen, the two I've used make or have options to make direct subroutine threaded calls. Dictionary structure is variable, and may even be eliminateable altogether (for turnkeying). But the ability to access the hardware and hi-level data structures, or to create the operators to do so at will; this is FORTH. That's why I don't buy into ASYST, and why I've never been much interested in FIFTH or other `protected' forths: I like the ones that have words like `see' and `view', the ones that encourage digging into the innards while not making it manditory. Directly tied to this is the immediate/compiled capability: being able to twiddle from the `command line', or compile the code into a word and use it over and over again. extensibility without testability is insanity. Spell it `C' (sorry, Mitch: I realize that C is not untestable. It's just harder for me, and takes longer in general.) This surely doesn't help: your position seems different (although I haven't had time yet for more than a hasty perusal), and I'm sure there are others that feel I'm off track. Take this as a highly personal opinion from some- one who hasn't felt lost yet when asked `What is FORTH?'. raybro
wmb@MITCH.ENG.SUN.COM (Mitch Bradley) (12/05/90)
My two favorite Forth attributes are the ease of creating a new definition and the ability to decompile. I tend to do a lot of "polishing" on my code, and that often involves factoring out subordinate functions. Forth definitions have very little "boilerplate", so the psychological barrier to creating a new one is minimal. The decompiler helps me to remember what something does and how it works. The need for a decompiler is reduced in an environment where the source is always on-line, but I routinely use a variety of different machines with different I/O configurations. The source code is often inconvenient to access, but the decompiler is always there. For me, relatively small amounts of inconvenience can significantly affect the way I work. Mitch Bradley, wmb@Eng.Sun.COM
ir230@sdcc6.ucsd.edu (john wavrik) (12/14/90)
Mitch Bradley writes,
# I have a tremendous amount of experience trying to "sell" Forth to
# other people. I have "sold" it to the world's leading workstation
# vendor, an entrenched "C" shop. As a result, there are 100,000 more
# Forth interpreters than there were a year ago.
# I found that talking about features was pretty much a waste of time.
# You pretty much have to prove your point by showing people what you
# and they can do with Forth. In my experience, the number of people
# who are swayed by technical arguments is negligeable.
# In the final analysis, it often boils down to: Can I hire someone
# to solve the problem for me, in a language for which I can later
# hire someone to support it? How much will the total project cost?
# That's where the market acceptance comes in.
We tend to forget that lots of different people do lots of different
things. Engineers who produce products are often not the same people
as salesmen who sell them, researchers who design them, executives who
decide to buy them, or teachers who explain their underlying
principles. While Mitch Bradley is writing boot proms for SUN Work-
stations, I will be in San Antonio (in March) talking to a group
of computer scientists interested in Computer Science Education. I
will be explaining to them some of the ways I have found Forth useful
in teaching computer science to college students -- and why they might
find it worthy of consideration. I know from past experience that
these people tend to think of computer languages in terms of language
characteristics. I also know that there is no way to be too informed.
I have a strong feeling that my audience will not be impressed if I
tell them that Forth is a good language because it's a lot like Mitch
Bradley's wife.*
Many (all?) computer languages get accepted because they are taught.
A language gets taught because it has certain characteristics.** It
may be that these characteristics serve as "training wheels" to teach
students good programming habits. Or it may be that these
characteristics make the language suited for a particular class of
"real" applications.
Changing computer language is a major time committment for most people
-- they don't do it unless that have good reason to believe that the
new language will perform better than the old. They certainly must put
in an effort to explore the new language in their own field -- but
getting them to this stage is critical. There are things that can be
said, and must be said, about a language to get them to this point.
I quite understand that many people don't have anything to say about
the characteristics of programming languages. Some people do, however.
I, for one, have good reason to want to hear what others have to say
on the subject. The topic "What makes Forth Forth?" is quite
legitimate. Not only is it interesting in its own right, but it does
have bearing on attempts to extend the acceptance of the language (to
say nothing of attempts to standardize it).
===============
* This is not a negative reflection on Mitch Bradley's wife. I don't
know Mitch Bradley's wife -- but I'm sure I will like if she's as
much like Forth as Mitch says. 8-)
** Although there is more to getting a language taught than this.
John J Wavrik
jjwavrik@ucsd.edu Dept of Math C-012
Univ of Calif - San Diego
La Jolla, CA 92093 ir230@sdcc6.ucsd.edu (john wavrik) (12/15/90)
Here are two events from Forml 1990 that inspired some questions on
the subject of "What makes Forth Forth".
I.
At FORML, Robert Smith told of reading some source code in which the
phrase "2 DROP" occurred. He found it hard to understand why anyone
would want to put a literal on the stack and then immediately drop
it -- so he asked the author. The author's response was that he
though it would be more useful to have DROP take an argument -- so
in his version of Forth, "<n> DROP" means to drop the top n numbers
on the stack. Everyone chuckled.
I thanked God that the author of the code, whoever he is, has not
managed to sell 500 copies of his version -- which would make him a
"major vendor" and a power to be reckoned with. [It would be back to
the thesaurus time on the old X3J14 ranch -- and we might all find
ourselves using FORSAKE or even CHUCK instead of DROP so that we do
not break anyone's code.]
To what extent is the proper choice of primitive words what makes
Forth Forth? Does the proper choice of capabilities at the very
lowest level (control over the input stream, control over
compilation, control over memory allocation, control of search
order, etc) determine the nature of the language. Which words are
essential -- which are negotiable -- which are vendor options? --
which are programmer options? Is the admittedly political method
used to produce a new Standard designed to preserve essential
features of the language?
II.
Wil Baden treated us to a one hour presentation to show the
machinations with extended versions of high level control words that
are needed to code tangled control flow problems. Baden has done an
excellent job in showing what is needed if we trade low-level
flexibility in defining new control structures for an expanded set
of higher level words (the usual IF, ELSE, etc. together with new
words like BUT, SO, and ALTHOUGH). [The status of these is uncertain.
I've been told that they have not been accepted in complete form by
the ANSI committee.]
The use of high level words can be quite awkward for building new
control structure words. A natural question to ask is why not provide
BRANCH and ?BRANCH (as found in FIG-Forth and is sucessors) -- from
which all these and yet other things can be built? Apparently the
problem is that there is no vendor agreement about the additional
information that control words put in the stack. Without this
agreement to make lower level words work, we are stuck.
To what extent is Forth Forth because (initially) things were
standardized at a low level? To what extent will Forth lose its
power and its character if it is standardized at too high a level?
John J Wavrik
jjwavrik@ucsd.edu Dept of Math C-012
Univ of Calif - San Diego
La Jolla, CA 92093