[Haskell] modern language design, stone age tools

MR K P SCHUPKE k.schupke at imperial.ac.uk
Wed Jun 23 07:34:20 EDT 2004


>Unless, of course, you have:
>1) A large program operating on a large body of data that takes a long time to

debugs logs go to a file, grep and awk let you quickly find things

>3) A complex library written by someone else which contains a bug or makes

before calling out print a funtion trace like:

function "f" called from "reified location" with arguments ...

returned "value"

>4) this is what assert statements are for as in:

        assert (x>0)
        function-which-assumes x>0


For large project development - the development cycle should go
along these lines...

        1) functional specification
        2) modularise
        3) design interfaces for components
        4) build testbench for components
        5) code components...

I have missed out the iterations for simplicity. Note the testbench
should be built before the module - this includes analysis for
linear regions and corner cases... The testbench will log each test
along with the results.

Testbenches should be provided with third party components - if they
are not they should be built as part of the development process.

I find if you do the above and put adequate debug logging in your
code the need for a separate debugger is minimal...

To get slightly more technical all the debugger does is run the code
with full internal visibility (all states visible) - by adding
debug statements you can increase visibility to the same level. 
logging all these debug outputs to a file gives you the same 
observability as single stepping, but it is much quicker to
run the program at full speed and search the file. Prining out
the full program state (or scoped variables) at any point is
equivalent to a breakpoint.

Consider this as a suggestion of how to cope without a debugger - until
you find one you like...

	Keean.


More information about the Haskell mailing list