V5N3 - Complang

polyFORTH II
The Operating System and
Programming Language
designed especially for
REAL-TI M E
Robotics
Instrumentation
Process Control
Graphics
... and many more.
polyFORTH II has the high-per-
formance features you need to
slash development time by months:
POWER
All the programming tools you
need - multiprogrammed OS,
FORTH compiler and assembler,
editor, over 400 primitives and de-
bugging aids - resident and ready
to use.
SPEED
3-5 times faster than Pascal, 20
times faster than Basic, with a resi-
dent assembler for time-critical
functions.
MULTITASKINGIMULTI-USER
Supports any number of tasks.
Even the smallest systems may
have two or more programmers
coding and testing interactively.
COMPACT CODE
Entire development system resi-
dent in under 12K. ROMable appli-
cations can run under 1K. Large
applications up to 10 times small-
er than with other techniques.
SUPPORT
On-line interactive documentation,
over a thousand pages of manuals,
FORTH Programming Courses,
and the FORTH, Inc. Hot Line plus
Contract Programming and Consulting
Services.
Available for most popular minis
and micros. From FORTH, Inc., the
inventors of FORTH, serving professional
FORTH programmers for
ten years.
FORTH, Inc.
2309 Pacific Coast Hwy.
Hermosa Beach
CA 90254
(213) 372-8493
TWX 91 0-344-6408
(FORTH INC HMBH)
'(tick). In 79-Standard, FIND wasn't of
much use so most people used the
state-smart '(tick). This led to
problems, since some state-smart
words must be used cautiously when
compiled within a colon definition.
The solution adopted was to make all
words state-dumb and to add words to
handle some of the lost functions. FIND
was later made useful, yet state-dumb
words remain.
A side effect of the state-dumb
"sweep" is that some words were made
statedumb that would have been bet-
ter left state-smart regardless of the
'(tick) decision. For example, there is
no reason why ABORT" should be state-
dumb. The system-dependent func-
tions associated with ABORT only
appear within ABORT". ABOFrl" could
have been of great use outside of a
colon definition, yet that has now been
precluded.
Some current systems use mono-
addressing (e.g.CFA or PFA), yet the
standard now dictates dual-addressing
(e.g.CFA and PFA). This tradeoff
favors an easier implementation and
was the subject of many hours of dis-
cussion. Some of the original dissen-
tors still believe that a mono-
addressing system is easier to use.
Disk (mass storage) I/O has been
changed to disallow altering the data
within a block buffer unless UPDATE is
also used. Even if EMPTY-BUFFERS
(which is no longer a required word)
were used, the alterations might still be
written to disk. Combined with the
multi-tasking implications, BUFFER can
no longer be used for a temporary
scratch or data collection area. Al-
though this codifies good program-
ming practice, there are valid reasons
why the standard should not be so
restrictive.
A minor but grating problem is that
the FST itself is always trying to allow
a wide variety of actual or possible im-
plementations. This has caused some
problems and ambiguities within the
standard. This is more an underlying
political problem than a technical one,
but the results affect the standard tech-
nically:
The ] (right-bracket) definition is
ambiguous. Different systems are im-
plemented such that the same sup-
posedly transportable standard
program produces different results on
the different systems.
Vocabularies have always been a
problem. The standard attempts to
resolve this issue, but actually leaves
some gaping holes. Because search or-
ders are not definitively stated, a stan-
dard program will have some difficulty
using vocabularies and search orders.
Consumers will have great difficulty
determining if a system is actually
Forth-83. Although this has always
been a problem, it will be worse this
time because 79-Standard systems
have been marketed. Implementors
will have difficulty determining or
choosing to make some of the subtle
changes from 79-Standard.
The standard should codify existing
practice. Instead, new concepts have
been accepted without a complete test-
bed existing with which to gain
experience. In most cases, these new
concepts are going to be proven
correct, but what about the ones that
aren't? Where will we be in four or five
years if next month we find that one of
these insufficiently tested concepts
causes a problem?
It is difficult to judge the impact of
some of these technical or philosophi-
cal concerns. Time and experience will
tell whether the decisions made for
Forth-83 were correct. Although it is
difficult, we must temper our frenzy
for having a new standard with a striv-
ing for reasonable perfection of the
standard.
FORTH Dimensions 28 Volume V, No. 3