Considering recursion

Functional languages generally avoid mutable variables by using recursion. This difference in focus means that you’re less apt to see logic errors that occur when loops don’t execute the number of times expected or fail to stop because the condition that you expected doesn’t occur. However, it also means that stack-related errors from infinite recursion happen more often.

You may think that loops and recursion produce similar errors. However, unlike a loop, recursion can’t go on indefinitely because the stack uses memory for each call, which means that the application eventually runs out of memory. In fact, memory helps define the difference between functional and other languages that do rely on loops. When a functional language runs out of memory to perform recursion, the problem could simply be that the host machine lacks the required resources, rather than an actual code error.

Understanding laziness

Haskell is a lazy language for the most part, which means that it doesn’t perform actions until it actually needs to perform them. For example, it won’t evaluate an expression until it needs to use the output from that expression. The advantages of using a lazy language include (but aren’t limited to) the following:

• Faster execution speed because an expression doesn’t use processing cycles until needed
• Reduced errors because an error shows up only when the expression is evaluated
• Reduced resource usage because resources are used only when needed
• Enhanced ability to create data structures that other languages can’t support (such as a data structure of infinite size)
• Improved control flow because you can define some objects as abstractions rather than primitives

However, lazy languages can also create strange bug scenarios. For example, the following code purports to open a file and then read its content:

withFile "MyData.txt" ReadMode handle >>= putStr

If you looked at the code from a procedural perspective, you would think that it should work. The problem is that lazy evaluation using withFile means that Haskell closes handle before it reads the data from MyData.txt. The solution to the problem is to perform the task as part of a do, like this:

main = withFile "MyData.txt" ReadMode $ handle -> do
myData <- hGetLine handle
putStrLn myData

However, by the time you create the code like this, it really isn't much different from the example found in the “Reading data” section of Chapter 13. The main advantage is that Haskell automatically closes the file handle for you. Offsetting this advantage is that the example in Chapter 13 is easier to read. Consequently, lazy evaluation can impose certain unexpected restrictions.

Using unsafe functions

Haskell generally provides safe means of performing tasks, as mentioned in several previous chapters. Not only is type safety ensured, but Haskell also checks for issues such as the correct number of inputs and even the correct usage of outputs. However, you may encounter extremely rare circumstances in which you need to perform tasks in an unsafe manner in Haskell, which means using unsafe functions of the sort described at https://wiki.haskell.org/Unsafe_functions. Most of these functions are fully described as part of the System.IO.Unsafe package at http://hackage.haskell.org/package/base-4.11.1.0/docs/System-IO-Unsafe.html. The problem is that these functions are, as described, unsafe and therefore the source of bugs in many cases.

You can find the rare exceptions for using unsafe functions in posts online. For example, you might want to access the functions in the C math library (as accessed through math.h). The discussion at https://stackoverflow.com/questions/10529284/is-there-ever-a-good-reason-to-use-unsafeperformio tells how to perform this task. However, you need to consider whether such access is really needed because Haskell provides such an extensive array of math functions.

The same discussion explores other uses for unsafePerformIO. For example, one of the code samples shows how to create global mutable variables in Haskell, which would seem counterproductive, given the reason you're using Haskell in the first place. Avoiding unsafe functions in the first place is a better idea because you open yourself to hours of debugging, unassisted by Haskell’s built-in functionality (after all, you marked the call as unsafe).

Considering implementation-specific issues

As with most language implementations, you can experience implementation-specific issues with Haskell. This book uses the Glasgow Haskell Compiler (GHC) version 8.2.2, which comes with its own set of incompatibilities as described at http://downloads.haskell.org/~ghc/8.2.2/docs/html/users_guide/bugs.html. Many of these issues will introduce subtle bugs into your code, so you need to be aware of them. When you run your code on other systems using other implementations, you may find that you need to rework the code to bring it into compliance with that implementation, which may not necessarily match the Haskell standard.

Relying on standard debugging

Haskell provides the usual number of debugging tricks, and the IDE you use may provide others. Because of how Haskell works, your first line of defense against bugs is in the form of the messages, such as error and CallStack output, that Haskell provides. Figure 16-1 shows an example of an error output, and Figure 16-2 shows an example of CallStack output. Comparing the two, you can see that they’re quite similar. The point is that you can use this output to trace the origin of a bug in your code.

During the debugging process, you can use the trace function to validate your assumptions. To use trace, you must import Debug.Trace. Figure 16-3 shows a quick example of this function at work.

You provide the assumption as a string in the first argument and the function call as the second argument. The article at http://hackage.haskell.org/package/base-4.11.1.0/docs/Debug-Trace.html gives additional details on using trace. Note that with lazy execution, you see trace output only when Haskell actually executes your code. Consequently, in contrast to other development languages, you may not see all your trace statements every time you run the application. A specialized alternative to trace is htrace, which you can read about at http://hackage.haskell.org/package/htrace.

Haskell does provide other debugging functionality. For example, you gain full access to breakpoints. As with other languages, you have methods available for determining the status of variables when your code reaches a breakpoint (assuming that the breakpoint actually occurs with lazy execution). The article at https://wiki.haskell.org/Debugging offers additional details.

Understanding errors versus exceptions

For most programming languages, you can use the terms error and exception almost interchangeably because they both occur for about the same reasons. Some languages purport to provide a different perspective on the two but then fail to support the differences completely. However, Haskell actually does differentiate between the two:

• Error: An error always occurs as the result of a mistake in the code. The error is never expected and you must fix it to make the code run properly. The functions that support errors are
  • error
  • assert
  • Control.Exception.catch
  • Debug.Trace.trace
• Exception: An exception is an expected, but unusual, occurrence. In many cases, exceptions reflect conditions outside the application, such as a lack of drive space or an incapability to create a connection. You may not be able to fix an exception but you can sometimes compensate for it. The function that support exceptions are
  • Prelude.catch
  • Control.Exception.catch
  • Control.Exception.try
  • IOError
  • Control.Monad.Error

As you can see, errors and exceptions fulfill completely different purposes and generally use different functions. The only repeat is Control.Exception.catch, and there are some caveats about using this function for an error versus an exception, as described at https://wiki.haskell.org/Error_vs._Exception. This article also gives you additional details about the precise differences between errors and exceptions.