Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!mit-eddie!bloom-beacon!think!ames!ncar!tank!uxc!uxc.cso.uiuc.edu!uicsrd.csrd.uiuc.edu!jaxon
From: jaxon@uicsrd.csrd.uiuc.edu
Newsgroups: comp.lang.apl
Subject: Re: debuggers
Message-ID: <49700004@uicsrd.csrd.uiuc.edu>
Date: 14 Oct 88 16:17:00 GMT
References: <109@infbssys.infbs>
Lines: 56
Nf-ID: #R:infbssys.infbs:109:uicsrd.csrd.uiuc.edu:49700004:000:2600
Nf-From: uicsrd.csrd.uiuc.edu!jaxon    Oct 14 11:17:00 1988


I don't understand the question.

    The interpreter itself (even one that implements the barest minimum
    required by the APL standard) already supplies 95% of the features 
    offered by the best interactive debuggers for other languages.  

    You should be able to use #TRACE and #STOP (formerly Tdelta and Sdelta)
    to inspect its run time behavior.   Extensions like monitorred variables,
    exception handling, trace windows, on-line help and others are not
    standard, but they are available from some APL vendors.  

    If you want hints about how to tackle writing a debuggable program...
       1) Write components that check their arguments, environment &
          results.  Write the checks as separate lines that halt the
          program when the check fails.  You can filter them out once
          its time to cut a production version.

       2) Don't optimize anything until most of the design bugs have been
          found and fixed.

       3) Write up a test program that unit tests components;
          Write a test script that integration tests the whole system; 
          Rerun the tests frequently while you're fixing bugs.  

    
    A few years ago Jim Ryan marketted an Sharp APL application that was
    a "programmer's workbench" (1981-83?)   IPSA or STSC probably have
    similar packages that help automate some of the program maintenance
    phase.
 
    There are some particular kinds of bugs for which APLers have 
    developed clever debugging methods, but I don't think anyone has
    published a collection.  Linda Alvord wrote an instructive paper
    for APL81 or APL83 covering APL "learning bugs", and there are
    certainly some bugs more common than others.   
 
Your question raises a lot of issues some dull, some deep.   Which ones
should we try discussing in this notesfile?   Maybe just anecdotes like
"The toughest bug I ever fixed..."  or  "My worst coding error..." would
be entertaining.  

I could suggest a few broad categories:

    Name conflicts due to dynamic scoping.
    Numerical precision problems (especially in portable software)
    Rank and shape errors.
    "How DID that variable get the value 0?, and how am I going to
     find the function that did it?"
    "It looked origin-independent, but it wasn't"
    IMPLICIT ERROR
    Exactly what order are names dereferenced and functions evaluated anyway?
    My predecessor left 500 one-liners and no documentation.  or worse:
    I believed the comment, now if only the interpreter could read it!

This newsgroup has been too dull lately, write something...