In the previous chapter you learned quite a few techniques for problem solving via calculation in Haskell It's time now to apply these ideas to a larger example, which will require learning even more problem-solving skills and Haskell language features.

Our job will be to design a simple module of geometric shapes, that is, a collection of functions and data types for computing with geometric shapes such as circles, squares, triangles, and others. Users of this module will be able to create new instances of geometric shapes and compute their areas. You will learn lots of new things in building this module, including how to design your own data types. Then in Chapter 4 we will extend this functionality with the ability to draw geometric shapes, and in Chapter 6 compute their perimeters.

In the description above I refer to the end product as a module, through which a user has access to certain well-defined functionalities. A module can be seen as a way to conveniently wrap up an application in such a way that only the functionality intended for the end-user is visible; everything else needed to implement the system is effectively hidden.

In Haskell we can create a module named Shape in the following way:

The “(…)” after the name Shape will ultimately be a list of names of the functions and data types that the end-user is intended to use, and is sometimes called the interface to a module. At the end of this chapter we will fill in the details of the interface once we know what they should be. The …body-of-module… is of course where we will place all the code developed in this chapter.

DETAILS

Module names must always be capitalized (just like type names).

A user of our shape module can later import it into a module that he or she is constructing, by writing:

Indeed, we will do exactly this in later chapters where new modules will be created in which users will be able to draw shapes, compute their perimeters, combine them into larger “regions,” color them, scale them, and place them on a “virtual desktop.”

In Chapters 2 and 8 we defined modules for geometric shapes and regions, respectively. We will now build a third layer onto this structure: a module that provides the ability to color regions and to place them on a “virtual desktop” in a graphics window. These colored regions will be called pictures. Once placed, you will be able to “click” on a picture using the mouse, which will cause that picture to rise to the surface of the desktop (i.e., any objects partially occluding it will be pushed beneath it). As usual, I will begin the discussion by providing the module interface:

Note that the Region module is imported and exported; and recall that the Region module includes the Shape module.

In this section Haskell's pattern-matching process will be explained in greater detail. Haskell defines a fixed set of patterns for use in case expressions and function definitions. Pattern matching is permitted using the constructors of any type, whether user-defined or predefined in Haskell. This includes tuples, strings, numbers, characters, and so on. For example, here's a contrived function that matches against a tuple of “constants:”

This example also demonstrates that nesting of patterns is permitted (to arbitrary depth).

Technically speaking, formal parameters to functions are also patterns – it's just that they never fail to match a value. As a “side effect” of a successful match, the formal parameter is bound to the value it is being matched against. For this reason, patterns in any one equation are not allowed to have more than dne occurrence of the same formal parameter.

A pattern that may fail to match is said to be refutable; for example, the empty list [ ] is refutable. Patterns such as formal parameters that never fail to match are said to be irrefutable. There are two other kinds of irrefutable patterns, which are summarized below.

The first pattern is known as a wildcard. Another common situation is matching against a value we really care nothing about. For example, the functions head and tail can be written as:

in which we have “advertised” the fact that we don't care what a certain part of the input is. Each wildcard will independently match anything, but in contrast to a formal parameter, each will bind nothing; for this reason more than one are allowed in an equation.

The second kind of irrefutable pattern in Haskell is called a lazy pattern, and has the form ̃pat.

Programming, in its broadest sense, is problem solving. It begins when we look out into the world and see problems that we want to solve, problems that we think can and should be solved using a digital computer. Understanding the problem well is the first – and probably the most important step in programming, because without that understanding we may find ourselves wandering aimlessly down a dead-end alley, or worse, down a fruitless alley with no end. “Solving the wrong problem” is a phrase often heard in many contexts, and we certainly don't want to be victims of that crime. So the first step in programming is answering the question, “What problem am I trying to solve?”

Once you understand the problem, then you must find a solution. This may not be easy, of course, and in fact you may discover several solutions, so we also need a way to measure success. There are various dimensions in which to do this, including correctness (“Will I get the right answer?”) and efficiency (“Will I have enough resources?”). But the distinction of which solution is better is not always clear, because the number of dimensions can be large, and programs will often excel in one dimension and do poorly in others. For example, there may be one solution that is fastest, one that uses the least amount of memory, and one that is easiest to understand. Choosing can be difficult and is one of the more interesting challenges that you will face in programming.

The last measure of success mentioned above – clarity of a program – is somewhat elusive, most difficult to measure, and, quite frankly, sometimes difficult to rationalize. But in large software systems clarity is an especially important goal, because the most important maxim about such systems is that they are never really finished! The process of continuing work on a software system after it is delivered to users is what software engineers call software maintenance, and is the most expensive phase of the so-called “software lifecycle.”

It is possible to use a language such as FAL to control thongs other than graphics images and animations. In particular, one could use FAL to control robots, not only in terms of their dynamic movement, but also their interaction with the real world. This is an interesting declarative approach to robot control that some researchers have in fact pursued. However, I will not do so here, for two reasons: First, there are no inexpensive, standard robots that I could use to make this effort truly worthwhile (although this may change over the next few years). Second, to demonstrate this idea using a graphically simulated robot would not make it significantly different from what I have already done with FAL.

Therefore, in this chapter I will describe a simple imperative language for robot control, using a simple graphics image to simulate the robot motion. My purpose is primarily to demonstrate the use of monads to implement stateful (i.e., imperative) computations. The language, which I will call IRL (for “imperative robot language”), is much less sophisticated than FAL, although it still qualifies as an embedded DSL.

The implementation also uses a new data structure, an array, as part of the representation of the state of the robot's world. An array is functionally no different from an indexed list, but is more efficient in access time.

IEL by Example

As I did with FAL, I will begin with a brief description of how to program in IRLS and return to its implementation in the next section. Being an imperative language, the essence of IRL is a set of commands. These operations must be sequenced properly to achieve some desired behavior. Not surprisingly, it is most convenient to use the do syntax to achieve this, implying that the underlying structure is a monad.

Recall that a polymorphic type such as (a → a) is really shorthand for ∀(a)a → a, which can be read “for all types a, functions mapping elements of type a to elements of type a.” Note the emphasis on for all.

In practice, however, there are times when we would prefer to limit a polymorphic type to a smaller number of possibilities. A good example is a function such as (+). It's probably not a good idea to limit (+) to a single (that is, monomorphic) type such as Integer → Integer → Integer, because there are other kinds of numbers - such as floating-point and complex numbers - that we would like to perform addition on. Nor is it a very good idea to have a different addition function for each type of number we wish to add, because that would require giving each a different name, such as addlnteger, addFloat, addComplex, and so on. And, unfortunately, we can't give (+) a type such as a → a → a, because this would imply that we could add things other than numbers, such as characters, lists, tuples, and any type that you might define on your own!

Haskell provides a solution to this problem through the use of qualified types. Conceptually, you can think of a qualified type just as a polymorphic type, except that in place of “for all types a” we will be able to say “for all types a that are members of class C”, where the class C can be thought of as a set of types. For example, suppose there is a class Num with members Integer, Float, and Complex. Then we could give an accurate type for (+), namely: ∀(a ε Num)a → a → a. But in Haskell, instead of writing ∀(a ε Num) … we will write Num a ⇒ ….

In this chapter simple graphics programming in Haskell will be explained. Graphics in Haskell is consistent with the notion of computation via calculation, although it is special enough to warrant the use of special terminology and notation. In the next chapter we will use the techniques learned here to draw in a graphics window the geometric shapes defined in the last chapter. The ideas developed in this chapter will be put into a module called SimpleGraphics:

There are many predefined functions and data types in Haskell, so many, in fact, that they demand some organization. Entities that are deemed essential to defining the fundamental nature of Haskell are contained in what is called the Standard Prelude, a collection of modules defining various categories of functionality. Entities that are deemed useful but not essential are contained in one of several Standard Libraries, also a collection of modules. The entire Standard Prelude is automatically imported into every program that you write, whereas the Standard Libraries need to be imported module-by-module.

Unfortunately, there is no standard graphics library for Haskell yet, although there is one in popular use on Windows machines called Graphics. The basic graphics functionality that we will use is defined in a library called SOEGraphics, which is very similar to Graphics but is guaranteed to work with this textbook, whereas the Graphics library may evolve over time. To use SOEGraphics, it must be imported into the module that is using it, as follows:

Graphics is a special case of input/output (IO) processing in Haskell, and thus I will begin with a discussion of this more general idea.

Basic Input/Output

The Haskell Report defines the result of a program as the value of the name main in the module Main. On the other hand, the Hugs implementation of Haskell allows you to type whatever expression you wish to the Hugs prompt, and it will evaluate it for you.

In this chapter we will review some applications of dynamic optimization to economics. In Section 1 we develop two models of search to illustrate the use of dynamic programming in a stochastic setting. Section 2 analyzes the decision problem faced by a social planner who maximizes the utility of an infinitely-lived representative agent in a one-good neoclassical economy. In Section 3 we study the optimal investment policy of a competitive firm when the installation of capital is costly. Finally, in Section 4 we develop the Cass-Koopmans model of a dynamic competitive economy and use it to analyze the welfare cost of factor taxes. Section 5 concludes with a series of problems.

Search Models

Search theory provides a simple and yet interesting application of dynamic programming to economics. In the basic search model, wage offers drawn from a given distribution arrive at fixed or random intervals, and an agent simply decides whether to accept one of them and become employed or reject them and continue searching for a better opportunity. We have, then, a very simple problem in stochastic dynamic programming: The control is simply a take-it-or-leave-it decision, and the distribution of the state variables (the offers) is time-invariant and does not depend on either the state or the control.

The first part of this section introduces the basic “microeconomic” model of job search. In addition to its interest as an application of dynamic programming, this model provides a useful counterpoint to the neoclassical model of a competitive labor market.