On 5/5/07, Stefan O'Rear wrote:

On Fri, May 04, 2007 at 10:44:15PM -0700, Ryan Dickie wrote:

...

I've only written trivial applications and functions in haskell. But the title of this thread got me thinking.

In an imperative language you have clear steps, states, variables to watch, etc. What techniques/strategies might one use for a functional language?

I personally most often use a divide-and-conquer approach. I pick a point about halfway down the call stack, and add trace calls. If the subproblems are handled correctly, narrow scope to higher levels; otherwise narrow to lower levels. Repeat until you have a single misbehaving function.

Isn't that called binary search, instead of divide-and-conquer? BTW, how about adding assertion in Haskell? Can it be done? (I've searched in my GHC 6.4.2 library documentation, and can't find 'assert') Is there any way to automatically clean all the mess I've done in debugging/asserting (like removing all trace/assert expressions) when I compile Haskell source code? Or should I create a simple program to remove them?

Stefan

-- Demi masa..

Sorry, replying myself. On 5/5/07, Monang Setyawan wrote:

BTW, how about adding assertion in Haskell? Can it be done? (I've searched in my GHC 6.4.2 library documentation, and can't find 'assert')

This can be done using Assertions. Lines below are taken from the docs. Assertions assert :: Bool -> a -> a If the first argument evaluates to True, then the result is the second argument. Otherwise an AssertionFailed exception is raised, containing a String with the source file and line number of the call to assert. Assertions can normally be turned on or off with a compiler flag (for GHC, assertions are normally on unless optimisation is turned on with -O or the -fignore-asserts option is given). When assertions are turned off, the first argument to assert is ignored, and the second argument is returned as the result.

On May 10, 2007, at 10:19 AM, Jules Bean wrote:

The 'next step' is to move from testing by hand in ghci to writing quickcheck properties / smallcheck / unit tests for the functions.

I still don't understand the difference between QC and SC. Would someone kindly explain and provide an example or two of when SC should be used? Thanks, Joel -- http://wagerlabs.com/

Hi The basic advantages of SC (stolen from the user manual): * write test generators for your own types more easily? * be sure that any counter-examples found are minimal? * write properties using existentials as well as universals? * establish complete coverage of a defined test-space? * display counter-examples of functional type? * guarantee repeatable test results? The disadvantage is that if your program only crashes on larger expressions, it will probably take forever to find a counter example. Thanks Neil On 5/10/07, Jules Bean wrote:

Joel Reymont wrote:

...

On May 10, 2007, at 10:19 AM, Jules Bean wrote:

...

The 'next step' is to move from testing by hand in ghci to writing quickcheck properties / smallcheck / unit tests for the functions.

I still don't understand the difference between QC and SC. Would someone kindly explain and provide an example or two of when SC should be used?

The most important difference is that:

QC checks 'a random selection' of possible parameter values.

SC checks 'every possible' in some methodical way, stopping at a certain depth for recursive structures.

_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe