Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!columbia!rutgers!lll-lcc!ames!sdcsvax!sdcc6!ir230
From: ir230@sdcc6.ucsd.EDU (john wavrik)
Newsgroups: comp.lang.forth
Subject: Debugging in Forth
Message-ID: <3281@sdcc6.ucsd.EDU>
Date: Wed, 12-Aug-87 00:29:25 EDT
Article-I.D.: sdcc6.3281
Posted: Wed Aug 12 00:29:25 1987
Date-Received: Fri, 14-Aug-87 01:34:13 EDT
Organization: University of California, San Diego
Lines: 72


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