Content Listing

Summary

In Chapter 13 you learned how to progam dynamic, graphical animations in a highly abstract, declarative manner. But there is one thing missing: reactivity. That is, the ability of our animations to react to user input or other external stimuli. In Chapter 10 you learned how user input could alter a graphics image, so at first blush, doing so for animations would seem to be just as easy. The problem is, we have lifted our thought processes and programming style to a level where we are manipulating continuous, never-ending animations, and the notion of a discrete event, such as a mouse press, does not fit in so well. For example, try to write a program, at the level of Behaviors, for a simple ball that changes color from red to blue when the mouse is pressed. I think that you will find this to be quite difficult.

In solving this problem I will borrow some ideas from a (nonstandard) Haskell library called Fran, which is short for functional reactive animation. Fran, and the version of it that we will develop in this chapter, are examples of domain specific languages, or DSLs. A DSL is a language that is designed for a specific application domain, in this case reactive animations. Haskell is an excellent vehicle for directly implementing DSLs without having to create a new language from scratch. In this way we say that the DSL is embedded in Haskell, or that Haskell is the host language for the DSL. To distinguish our language from Fran, I will call it FAL, for functional animation language.

I will begin by describing FAL by example. I will then describe a partial implementation of FAL based on streams which, because of its simplicity, can also serve as its specification. Once this foundation is established, I will describe various extensions to FAL, culminating in a final example, a twenty-line program to play the game of paddleball.

Summary

In Chapter 3 you learned enough about IO programming in Haskell to handle the graphics tasks encountered in Chapters 4, 10, and 13. In this chapter we will take a closer look at IO programming in Haskell, including more examples of file operations, and several new ideas: file handles, exceptions, channels, and concurrency. Then in the next chapter I will show how these ideas can be put to use in defining the reactimate function introduced in Chapter 15 for rendering reactive animations.

The Standard Prelude contains the most basic IO commands, with more advanced ones found in the IO Library, the SOEGraphics Library that we have already seen, and several others. The IO Library contains quite a few useful operations for file manipulation. Rather than trying to remember which is in the Standard Prelude and which is in the IO Library, it's easier to always import the library if you are doing anything beyond the most basic 10 tasks.

Files, Channels, and Handles

The first new idea is the concept of a handle to a file. A file handle is not unlike the Window value returned from the openWindow command, where several windows maybe opened simultaneously, using the Window value to specify in which window subsequent actions are to take place. File handles work the same way. There may be more than one file that is open at the same time, and thus we need a way to distinguish among them.

To obtain a handle (of type Handle) to a file there is an operation for opening the file for use in subsequent IO operations. There is also an operation for closing a file via reference to its handle.

openFile :: FilePath → IOMode → IO Handle

hClose :: Handle → IO ()

Summary

MIDI is shorthand for “Musical Instrument Digital Interface,” and is a standard protocol for describing electronic music. In this chapter I will describe how to convert an abstract performance as defined in Chapter 21 into a MIDI file that can be played on any modern PC with a standard sound card.

module MDL where

import Music

import Perform

import Haskore (MidiFile (‥), MidiChannel, ProgNum, MEvent, MFType, Velocity, MEvent (‥), MidiEvent (‥), MetaEvent (‥), Division (‥), MTempo, outputMidiFile)

import List (partition)

import System (system)

As mentioned in Chapter 20, Haskore is a library for computer music that is more extensive than MDL, and I will borrow much of the basic MIDI data types defined there, as well as the low-level function outputMidiFile, to be described later.

An Introduction to MIDI

MIDI is a standard adopted by most, if not all, manufacturers of electronic instruments. At its core Is a protocol for communicating musical events (such as note on, note off, key press, pedal press) as well as socalled meta events (such as select synthesizer patch, change volume). Beyond the logical protocol, the MIDI standard also specifies electrical signal characteristics and cabling details. In addition, it specifies what is known as a Standard MIDI File, which any MIDI-compatible software package should be able to recognize.

Over the years musicians and manufacturers decided that they also wanted a standard way to refer to common or general instruments such as “acoustic grand piano,” “electric piano,” “Violin,” and “acoustic bass,” as well as more exotic ones such as “chorus aahs,” “voice oohs,” “bird tweet,” and “helicopter.” A simple standard known as General MIDI was developed to fill this role, It is nothing more than an agreed-upon list of instrument names along with a program patch number for each, a parameter in the MIDI standard that is used to select a MIDI instrument's sound. The constructor names in the IName data type (see Fig. 20.1. In Chapter 20) come directly from this standard.

Summary

The functional animation language FAL was defined in Chapter 15. In this chapter we will explore a method to render FAL programs in a graphics window. The fundamental challenge will be interfacing FAL, arguably the most abstract programming style introduced in this textbook, to the relatively low-level interface to graphics windows provided by the Graphics Library.

module Reactimate where

import Fal

import SOEGraphics hiding (Region, Event)

import qualified SOEGraphics as G (Region, Event)

import Draw (xWin, yWin, intToFloat)

import Win32Misc (timeGetJime)

import Word (word32ToInt)

import Channel

Preliminaries

Analogous to the function animate in Chapter 13, our goal is to define a function, which I will call reactimate, having type:

reactimate :: String → Behavior a → (a → IO Graphic) → IO ()

Before doing this, however, there is an important secondary task to be carried out. We need a mechanism to extract a stream of time-stamped user actions (lifted into the Maybe data type) from the operating system. We want the stream of user actions to be infinite, and return Just ua if there is a user action ua present at the time we ask for it, and Nothing if there is not. The problem is the phrase “at the time we ask for it.” How can we make a stream dependent on the execution time of a program? Surely we will need to go through the IO monad to achieve this dependency, and, in fact, I will use the Channel abstraction discussed in Chapter 16 to do so. For now, however, let's assume that we have a function:

windowUser :: Window → IO (([Maybe UserAction], [Time]), IO ())

which behaves as follows. Executing the command:

((us, ts), addEvents) ← windowUser w

in a particular window environment yields a user action stream us and time stream ts. In addition, it yields an IO action addEvents that causes the operating system to update us with whatever user actions happen to be pending at that time, followed by a Nothing to indicate that there are no more user actions pending.

Summary

The first high-level languages developed for general purpose programming were Fortran (Backus, 1978) and Lisp (McCarthy, 1978), developed in the late 1950s by John Backus and John McCarthy, respectively. From Fortran grew many of today's modern imperative languages, most of which did not improve significantly on the fundamental ideas found in the language Algol (de Morgan, Hill and Wichmann, 1976), which shortly followed Fortran. The Lisp family was less fecund, perhaps because it was so far ahead of its time, but was the seed for the family of functional languages about which this textbook was written. The most radical in this class of languages is probably Haskell, originally designed in the late 1980s (Hudak, Wadler, 1988) based on, at that point, a good ten years of experience designing and implementing similar languages, most notably a series of languages developed by David Turner in the late 1970s and early 1980s (Turner, 1976; 1985). Although research continues on the design of Haskell, the version used in this textbook, Haskell 98 (Augustsson, et al., 1999), is the latest and most stable version of the language and its libraries.

Haskell was named after the logician Haskell B. Curry who, along with Alonzo Church, established the theoretical foundations of functional programming back when computers themselves were only a gleam in researchers' eyes. A curious historical fact is that Haskell Curry's father, Samuel Silas Curry, helped to found and direct a school in Boston called the School of Expression. Because pure functional programming centers around the notion of an expression, I thought that The Haskell School of Expression would be a good title for this book.

A Brief Account of Language Success Stories

It's hard to predict just how it is that a language becomes popular. Fortran became popular because it was the first high-level language and a welcome alternative to assembly language, and ultimately because it was a good vehicle for coding numerical algorithms in the domain of scientific computing.

Summary

In this chapter I will describe a module for expressing musical structures in the same high-level, declarative style of functional programming that we have been using for graphics, animation, and other applications. These musical structures consist of primitive entities (such as notes and rests), operations to transform musical structures (such as transpose and tempo-scaling), and operations to combine musical structures to form more complex ones (such as concurrent and sequential composition). From these simple roots, much richer musical ideas can be easily developed.

For convenience, and in the style of Chapters 15 and 19 (where I defined the languages FAL and IRL, respectively), I will refer to the ideas described in this chapter as MDL, for music description language. MDL is a simplified version of a more complete computer music library called Haskore. In Chapter 21a module will be developed for interpreting an MDL program as an abstract performance, and in Chapter 22 these performances will be converted into MIDI files, which are a standard way of interchanging electronic music and can be played on any PC with a standard sound card.

DETAILS

If you load the Haskell code for Chapter 22 into Hugs you will be able to play any of the examples presented in this chapter by typing either:

testWin95 m

testNT m

testLinux m

depending on what kind of computer you are using. This command will convert m (of type Music to be defined shortly) into a MIDI file, and then automatically invoke the default MIDI file player on your PC so that you can hear the result.

module Music where

The Musk Data Type

I will assume that you are familiar with very basic musical concepts such as notes, rests, scales, and chords. Nothing more will be needed to understand what is going on, but of course the richer your musical background, the more applications of the ideas will be apparent to you.

Summary

In previous chapters you learned how to draw simple geometric shapes in a graphics window. Although you also learned how to manipulate these pictures somewhat using the mouse, they were otherwise static. In this chapter I will explain how to make these pictures dynamic; that is, how to program animations. In doing so you will learn several new ideas, such as how to use timers and how to use polymorphism and type classes in unique ways.

module Animation where

import Shape

import Draw

import Picture

import SOEGraphics hiding (Region)

import qualified SOEGraphics as G (Region)

import Win32Misc (timeGetTime)

import Word (word32ToInt)

What is an Animation?

An animation is a continuous, time-varying image. However, the animations that you see in the movies, on TV, or on your computer screen only seem to be moving continuously. In reality they are created by a sequence of static images - called frames that are displayed in such rapid succession that they appear to be continuous to the human eye. The rate at which this phenomenon occurs is somewhere between 20 and 30 times per second, depending on lighting conditions and other factors. I will use the rate of 30 times per second, or 30 Hertz, abbreviated 30 Hz. Televisions, computers, and motion pictures all use this fundamental physiological phenomenon to give the illusion of continuous movement.

So the question is, how do we program an animation? The only graphics 10 operation that we have discussed so far is drawInWindow, but note that drawing things using this operation is accumulative. That is, we never erase anything, nor even do so much as clear the screen. Even the user interaction given in Chapter 10 does not clear the screen; each successive rendition of the stack of regions is drawn right over the previous rendition. This works because each new picture completely hides the old one.

This will not work, however, if we are drawing a person walking across the screen, or a ball bouncing in a box.

Summary

All of the types considered thus far have been first order. For example, the type constructor Tree has always been paired with an argument, as in Tree Int (a tree containing Int values) or Tree a (representing the family of trees containing a values). But Tree by itself is a type constructor: something that takes a type as an argument and returns a type as a result. There are no values in Haskell that have this type, but such “higher-order” types can be used in class declarations in useful ways, as we shall see in this chapter.

The Functor Class

To begin, consider the following Functor class defined in the Standard Prelude:

class Functor f where

fmap :: (a → b) → f a → f b

DETAILS

Type applications are written in the same manner as function applications, and are also left associative: The type T a b is equivalent to ((T a) b).

There is something new here. The type variable f is applied to other types, as in f a and f b. Thus, we would expect f to be a type such as Tree, which can be applied to an argument. Indeed, a suitable instance of Functor for type Tree would be:

instance Functor Tree where

fmap f (Leaf x) = Leaf (f x)

fmap f (Branch t1 t2) = Branch (fmap f t1) (fmap f t2)

Recall that in Section 7.2 we defined a function mapTree that behaved just as the above fmap method, so we could have instead written:

“instance Functor Tree where

fmap = mapTree

Such an instance declaration declares that Tree, rather than Tree a, is an instance of Functor.

Note that in Haskell we write Tree Int for trees of integers, and we say that Tree is a type constructor. And we write [Int] for lists of integers. However, what is the type constructor for lists? Because of Haskell's special syntax for the list data type, there is also a special syntax for its type constructor, namely [].

Summary

Recall that in Chapter 6 we used an infinite list to simulate a mathematical sequence used in the calculation or the perimeter of an ellipse. When a list is used in a context where it will always he infinite, it is commonly called a stream, Many problems can be elegantly, concisely, and efficiently expressed using streams, which we will explore in this chapter. With the power of streams there are also inherent dangers, which we will also explore. In the next chapter we will use streams in a central way in the implementation of a language for expressing reactive animations.

Lazy Evaluation

Because streams are never finite, it would seem natural to define a special polymorphic data type for them, such as:

data Stream a = a : Stream a

Although we could certainly do this, it is more convenient to use Haskell lists to “simulate” streams by just never using the empty list constructor []. The main advantage of this approach is that we can then reuse many polymorphic functions already defined on lists rather than redefining them on a new data type.

In Chapter 6 we used list comprehensions to create the infinite list [2, 2.], but is there a more fundamental way to create this list? Here is one way:

twos = 2 : twos

Let's compute this value by calculation:

twos

⇒ 2 : twos

⇒ 2 : 2 : twos

⇒ 2 : 2 : 2 : twos

…

There is, of course, no end to this calculation, An important distinction exists, however, between this calculation and ones that we have labeled as “infinite loops” and given the value ⊥ in previous chapters: this calculation is producing useful information, namely the successive elements of a list. Its value is an infinite list, or stream, A stream contains an infinite amount of information, whereas ⊥ contains no information whatsoever.

DETAILS

Try running this example, in Hugs, if you type twos to the evaluation prompt, it will go into an infinite loop printing 2's.

Now consider the expression head twos.

Summary

You have now seen several examples where functions are passed as arguments to other functions, such as with fold and map. In this chapter, I will show several examples where functions are also returned as values. This will lead to several techniques for improving definitions that we have already written - techniques that we will use often in the remainder of the text.

Currying

The first improvement relates to the notation we have used to write function applications, such as simple x y z. Although I have noted the similarity of this to the mathematical notation simple(x, y, z), in fact, there is an important difference, namely that simple x y z is actually equivalent to (((simple x) y) z). In other words, function application is left associative, taking one argument at a time.

Let's look at the expression (((simple x) y) z) a bit closer: There is an application of simple to x, the result of which is applied to y; so (simple x) must be a function! The result of this application, ((simple x) y), is then applied to z, so ((simple x) y) must also be a function!

Because each of these intermediate applications yields a function, it seems perfectly reasonable to define a function such as:

multSumByFive = simple 5

What is simple 5? From the above argument, we know that it must be a function. And from the definition of simple in Section 1.1, we might guess that this function takes two arguments, and returns 5 times their sum.

Indeed, we can calculate this result as follows:

multSumByFive a b

⇒ (simple 5) a b

⇒ simple 5 a b

⇒ 5 * (a + b)

Summary

The use of lists is particularly common when programming in Haskell, and thus, not surprisingly, there are many predefined polymorphic functions for lists. The list data type itself, plus some of the most useful functions on it, are contained in the Standard Prelude's PreludeList module, which I will cover in detail in this chapter. There is also a Standard Library module called List that has additional useful functions. It is a good idea to become familiar with both modules.

Although this chapter may feel like a long list of “Haskell features,” the functions described here capture many common patterns of list usage that have been discovered by functional programmers over many years of trials and tribulations. In many ways higher-order declarative programming with lists takes the place of lower-level imperative control structures in more conventional languages. By becoming familiar with these list functions you will be able to more quickly and confidently develop your own applications using lists. Furthermore, if all of us do this, we will have a common vocabulary with which to understand each others' programs. Finally, by reading through the code in this module you will develop a good feel for how to write proper function definitions in Haskell.

It is not necessary for you to understand the details of every function, but you should try to get a sense for what is available so that you can return later when your programming needs demand it. In the long run, you are well-advised to read the rest of the Standard Prelude as well as the various Standard Libraries, to discover a host of other functions and data types that you might someday find useful in your own work.

The PreludeList Module

To get a feel for the PreludeList module, let's first look at its module declaration:

module PreludeList (

map, (++), filter, concat,

head, last, tail, init, null, length, (!!),

foldl, foldl1, scanl, scanl1, foldr, foldr1, scanr, scanr1,

iterate, repeat, replicate, cycle,

take, drop, splitAt, takeWhile, dropWhile, span, break,

lines, words, unlines, unwords, reverse, and, or,

any, all, elem, notElem, lookup,

Summary

In Chapter 20 I defined a language called MDL for describing musical structures. The question now is, how do we actually interpret the structures; that is, how do we turn them into real music? (This is analogous to the question of how to draw a Shape or Region value in a graphics window.) The approach I will take will be to convert a Music value into a Standard MIDI File, which can then be played on your computer using any standard media player. I will do this, however, in three steps:

Summary

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:

module Shape (…) where

…body-of-module…

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:

import Shape

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.”

Summary

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:

module Picture (Picture (Region, Over, EmptyPic),

Color (Black, Blue, Green, Cyan, Red, Magenta, Yellow, White),

regionToGRegion, shapeToGRegion,

drawRegionlnWindow, drawPic, draw, spaceClose,

module Region

) where

import Draw

import Region

import SOEGraphics hiding (Region)

import qualified SOEGraphics as G (Region)

DETAILS

The last two lines above look strange, and arise because both the Region module and the SOEGraphics module define a data type called Region, so importing them both into the same module causes a name clash, which Haskell (quite sensibly) does not. allow. In order to use them both, I first import afl of the SOEGraphics module except for Region; that's what the next to the last line does. Then I import SOEGraphks as a qualified module, at the same time renaming if to G, and furthermore I only import Region from it, All of this is achieved by the last line above, The end result is that in the Picture module, the Region data type defined in SOEGraphics has the name G.Region, whereas the one from module Region is just called Region. (If I had omitted “as G” from the last line above, then the new Region type would be referred to as SOEGraphics. Region.)

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

Summary

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:”

contrived :: ([a], Char, (Int, Float), String, Bool) → Bool

contrived ([], ′b′ (1, 2.0), “hi”, True)

= False

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:

head (x :-) = x

tail (-: xs) = xs

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.

Summary

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.”

Textbooks

Refine search

Refine search

Actions for selected content:

Save Search

37953 results in Cambridge Textbooks

Summary

Summary

Summary

Summary

Summary

Summary

Summary

Summary

Summary

Summary

Summary

Summary

Summary

Summary

Summary

Summary