ir230@sdcc6.ucsd.edu (john wavrik) (08/15/90)
Dr. Eaker's "English" syntax is realized in the statistical language
Minitab. Some of the objections raised to his fast-food example do not
exist in this case -- because of special features of the situation.
Minitab operates on a spreadsheet. The only data for a command are
column numbers C1, C2 ... and numbers. The command is the first word
in a line -- anything not a column or number is noise. Here are
examples:
ORDER THE NUMBERS IN C1, PUT THE REARRANGED NUMBERS IN C2
but
ORDER C1 C2 does the same thing
GENERATE THE FIRST 50 INTEGERS AND PUT THEM IN C1
but
GENERATE 50 C1 does the same thing and so does
GENERATE THE INTEGERS UP TO 50, PLEASE,
AND AFTER YOU ARE DONE WILL YOU KINDLY
INSERT THEM IN THE COLUMN NAMED C1,
THANKS.
The command line can be verbose and free-form since it is only the
leading command words and the arguments that are meaningful. (I gave
away the trick prematurely -- to someone who doesn't know it, Minitab
seems to have a very good command of English.)
Many years ago I tried developing this on an algebra package. At
the time I believed what I was told: that most people find
Forth's Reverse Polish Syntax hard to understand and that I would
have to do something about it. While a surface language of this
sort does make a system more palatable to some people, a simple
explanation of how Forth works has proved to be just as good for
others.
I should mention the two approaches I used:
1. Use a method similar to that posted by Dr. Eaker in which
the words in a sentence are Forth words -- interpreted by
the outer interpreter. This requires that any noise words
be explicitly declared.
2. Make the first word a local interpreter of the input stream.
This allows the first word to search for its arguments and
treat everything else as noise -- it allows a wider range
of acceptable expressions.
There are a number of objections, besides the ones already raised, to
this idea.
1. The most significant objection to the first approach is that
there is no longer a good association between a word and its
action. Each word has an "under the table" action (Eaker's
"is" actually prints a number). Everything I know about
writing clear Forth suggests that I should choose names
carefully to suggest what they are designed to accomplish.
This approach can require a lot of hidden gymnastics to make
the syntax "come out right" and one finds that simple words
like "to", "at", etc. conceal major stack maneuvers. [Worse
yet, these connecting words get used up quickly. Eventually
you get to the point where some of these words open special
vocabularies so that connectives can have different meanings
in different contexts.]
2. The second approach has potential -- in effect it uses Forth's
control over the input stream and over compilation and
interpretation to create a compiler/interpreter for a new
language. Like Minitab, the language has a stylized syntax
(command word first followed by a somewhat free English-like
phrase containing the arguments). It worked nicely as a
surface language over an existing Forth application. It began
to get complicated when programmability was added to the
language. [Minitab has only rudimentary programming
capability]
There are applications (like Minitab) where an English-like
syntax is quite viable -- where the range of acceptable phrases
can be wide because the range of real data within a phrase is
simple. [Essentially, where you can say the same thing in a
variety of ways because the range of discourse is limited.]
I've convinced myself (connecting this with Wil Baden's posting
on style) that good Forth consists of a sequence of
understandable actions with well chosen names -- thus the code I
write is not grammatical English. I'd like to see more examples
from those who have a more COBOL outlook on life. Are these
approaches which are in opposition or is "readability" in the
sense of English something that can be brought to a more
traditional approach to Forth coding.
P.S. The promised article on permutations will be posted
when I get back from vacation.
John J Wavrik
jjwavrik@ucsd.edu Dept of Math C-012
Univ of Calif - San Diego
La Jolla, CA 92093