Debugging F# code and functional style

Question

I'm new to funcctional programming and have some questions regarding coding style and debugging.

I'm under the impression that one should avoid storing results from funcction calls in a temp variable and then return that variable

e.g.

let someFunc foo =
    let result = match foo with
                 | x -> ...
                 | y -> ...
    result 

And instead do it like this (I might be way off?):

let someFunc foo =
    match foo with
    | x -> ...
    | y -> ...

Which works fine from a functionallity perspective, but it makes it way harder to debug. I have no way to examine the result if the right hand side of -> does some funky stuff.

So how should I deal with this kind of scenarios?

Answer 1

I wouldn't shoot you if you used the temp, but I also wouldn't cramp my style on the off chance that I needed to watch something under debug.

Besides, debugging this sort of thing is much easier with Visual Studio 2010's visual debugger, as you can use breakpoints inside each possible match expression. There is also quick watch and other great features.

For a list of the latest features in the Visual Studio debugger: http://msdn.microsoft.com/en-us/library/01xdt7cs.aspx

Answer 2

Either way is acceptable, as you are simply binding to local immutable variable.

There is a catch though. If you using it as part of a recursive loop using tail calls, the one using the temp variable will eliminate the tail call, and hence you will have an increase in stack space.

Answer 3

Being able to see the return value of a function in VS is a long-standing request. Other intermediate expression values too; in F# for example, you often want to inspect the middle of a pipeline, which is hard to do. In the sense that functional programming means "fewer named variables and locals" and "larger expressions", this does have a negative impact on the current generation of debuggers. (On the other hand, with things like less mutability and higher abstraction, hopefully you spend less time in the debugger.)

There are still many ways the debuggers of the future can be improved...

See also

http://stackoverflow.com/questions/1894636/do-some-functional-programming-constructs-reduce-debuggability