ir230@sdcc6.ucsd.EDU (john wavrik) (08/12/87)
Tim Born writes:
My fondness for Forth has waned in recent months due to the (apparent)
lack of debugging tools available. I guess I'm spoiled by my UNIX
environment, with tracers & symbolic debuggers and all .....
I appeal to those of you who have so much more experience in this area
than I: what are the "tricks of the trade"?
I venture to guess that there are others who follow this group who are
reasonably intelligent folks who just haven't caught on to thinking
in Forth. I open myself up to your collective wisdom - I dare you to
show me that Forth can be used without going bald from banging ones head
against the walls.
------------------------------
The main secret to debugging in Forth lies in making maximum use of the
interactive nature of the language. An application is built up in small
pieces and tested as it is built. Since the environment doesn't disappear
when the "program" has finished running, one can always examine the changes
made by a word after it executes. Component words can be executed from the
keyboard for testing purposes.
A unique style of writing has developed in the Forth community which
decreases the chance of errors in the first place and which simplifies
debugging: applications are written using a lot of small words (definitions a
few lines each). Definitions are "factored" to avoid deeply nested conditional
structures or loops (keeping the logical structure of each word simple). And
(to repeat) code is tested as it is written. A good reference for this style
of writing is "Thinking Forth" by Leo Brodie. An illustration of the style is
a loop word:
: ALOOP 1000 0 DO condition IF doit ELSE don't THEN LOOP ;
The words "condition", "doit", "don't" may themselves contain loops and
conditions --- but the structure of ALOOP is simpler and easier to check
in this "factored" form than if the calls to these words were to be replaced
by their definitions. Even if these three words are not used anywhere else in
the application, their definition as separate words may be justified if it
makes ALOOP easier to debug. A Forth programmer may use 40 or more words in an
application to produce 5-10 "top level" words. Below a top level word there
may be a hierarchy of as many as 6 or 7 levels until basic Forth "system"
words are encountered.
The students who have the most trouble with Forth are those who insist
on bringing to it habits from other languages (e.g. The "C" wizard who hates
blocks, so writes a program to convert text files -- and uses a conventional
editor. He writes words whose definitions are 7 screens long with loops and
conditionals 5 levels deep. The stack within his word would be up to 6
numbers deep -- if it executed correctly.) Conventional languages seem to
encourage the production of large untested blocks of code which (in any
language) can be hard to debug!
Well written Forth is relatively quick to write and relatively easy to
debug. The tools you mention are not often used in Forth because Forth is not
a purely compiled language. Many of us have had the experience of writing
debugging tools when we started the language only to find them shelved
subsequently. (A few Forth systems do, by the way, offer at least breakpoint
and trace facilities.)
Forth is implemented in a very simple way. You can build diagnostic tools
of your own, but you'll probably find that anything that really requires heavy
debugging tools should be rewritten.
Exploit the interactive nature of the language, build your applications in
layers, factor your words, keep your definitions short and simple, and test as
you go along --- you'll find your hair growing again in no time!
--John J Wavrik
Dept of Math
Univ of Calif - San Diego
...ucbvax!sdcsvax!sdcc6!ir230
ir230%sdcc6@SDCSVAX.UCSD.EDU
collinge@uvicctr.UUCP (08/14/87)
In article <3281@sdcc6.ucsd.EDU> ir230@sdcc6.ucsd.EDU (john wavrik) writes: >>Tim Born writes: >>My fondness for Forth has waned in recent months... > > The main secret to debugging in Forth lies in making maximum use of the >interactive nature of the language... Much to my amazement, I have found this, too. I was a somewhat reluctant user of Forth initially, scared off by all those things everyone hates about Forth, but now that I have made several fairly large systems in it I have to agree, getting things to work is just EASIER in Forth. Even without ANY debugging tools at all. Indeed, who needs them? I've done about three fairly complex things now - all done in a coffee and beer stupor in about 36 straight hours, with my friend and me prodding each other to keep awake - and they have all come up smoothly, without a hitch. In every case, the major glitches were eventually traced to hardware problems - debugging tools aren't going to help you there! I have found myself taking my good Forth habits to my C coding and producing the same good results, except that it all so much more tedious in C... -- Doug Collinge School of Music, University of Victoria, PO Box 1700, Victoria, B.C., Canada, V8W 2Y2 collinge@uvunix.BITNET decvax!uw-beaver!uvicctr!collinge ubc-vision!uvicctr!collinge