The real driving factors behind the new economy are flexibility, agility, and time to market. Obviously, this means speeding the desired e-Applications to market in the first place. However, speed also involves how quickly your company can respond to market changes by rolling out new, iterative versions of e-Enterprise platforms. Sometimes emerging technology standards that enable exchange of information between partners and stakeholders drive these changes. Sometimes they are driven by shifts in the external business landscape such as new market opportunities. Still other times they result from concerted analysis and process engineering driven by internal corporate forces.

As discussed in Chapters 5 and 6, the key to enabling this perpetual business, application, and technology change is a reusable repository of operating models and infrastructure that embody the common functionality shared by multiple e-Applications. Therefore, this repository must store the high-level business services that provide cross-functional business/application functionality and the technology components that aid in producing the underlying technology infrastructure. These high-level business services are known as application or business components. The combination of business and technology components provides the backbone not only for the repository, but also for the iterative design and deployment methodology that is integral to the concept of the e-Enterprise.

Although the concept of technology components has been around for some time, the concept of business components is still in its infancy.

In this chapter I will introduce two new important ideas. The first is poly-morphism, the ability to consider entire families of types as one. Polymorphic data types are one source of this concept, which is then inherited by functions defined over these data types. The already familiar list is the most common example of a polymorphic data type, and it will be discussed at length in this chapter.

The second concept is the higher-order function, which is a function that can take one or more functions as arguments or return a function as a result (functions can also be placed in data structures, making the data constructors higher-order too). Together, polymorphic and higherorder functions substantially increase our expressive power and our ability to reuse code. You will see that both of these new ideas naturally follow the foundations that we have already built. (A more detailed discussion of polymorphic functions that operate on lists can be found in Chapter 23.)

Polymorphic Types

In previous chapters we have seen examples of lists of many different kinds of elements integers, floating-point numbers, points, characters, and even 10 actions. You can well imagine situations requiring lists of other element types as well. Sometimes, however, we don't wish to be so particular about the precise type of the elements. For example, suppose we want to define a function length, which determines the number of elements in a list. We don't really care whether the list contains integers, characters, or even other lists. We imagine computing the length in exactly the same way in each case. The obvious definition is:

This definition is self-explanatory. We can read the equations as saying: “The length of the empty list is 0, and the length of a list whose first element is x and remainder is xs, is 1 plus the length of x.s”

But what should the type of length be? Intuitively, what we'd like to say is that, for any type a, the type of length is [a] → Integer.

In this chapter I will use ideas developed in the last chapter to extend the functionality of geometric shapes defined in Chapter 2. In particular, we will consider the problem of combining shapes into larger, possibly overlapping, regions. We will not be interested in computing the area or perimeter of these regions (no easy task, by the way, with the shapes allowed to overlap in arbitrary ways), but rather we will want to know whether a particular point lies within a region. Regions are thus located on a two-dimensional (i.e., Cartesian) plane.

The functionality that we develop will be encapsulated in a module called Region:

Note that this module imports the Shape module, and exports a data type called Region, functions containsS and containsR, and the entire Shape module.

The Region Data Type

Our first task will be to define a data type that captures the various kinds of regions that interest us:

We have so far only scratched the surface of the many kinds of useful data types that can be created in Haskell In this chapter I will introduce the use of recursive and tree-shaped data types. In the process we will look at a few motivating examples of trees, but will use them more concretely in the next chapter when we create a data type of geometric regions.

A Tree Data Type

In Chapter 2 we defined a data type called Shape:

Note that every value created of this type has the same relative size, except that the list of vertices in a polygon can be arbitrarily long. In fact, lists are an example of a data type whose elements can be of any size, from [ ] to a conceptually infinite list. Lists are built-in to the Haskell language, but if they weren't, we could easily define a data type that would behave in the same way:

There are two things different about this data type from ones we've defined earlier. First, it is polymorphic. This is indicated by the fact that the name of the type, List, takes a type as an argument. In other words, the principal types of the constructors are:

which are in direct correspondence with the types of Haskell's built-in list constructors:

The second important aspect of the List data type definition is that it is recursive. That is, the type List a is defined in terms of List a. This recursive structure is what allows lists to be arbitrarily long (or even infinite), just as a recursive function may be called an arbitrary number of times (or even loop forever).

E-TRANSFORMATION

In Chapter 1, I discussed how the Net is bringing about a fundamental change in the way corporations do business. For established “bricks-and-mortar” corporations, the Web was initially an after thought, a place for posting static product information and accepting credit card numbers and shipping addresses to make purchases. We called this “e-Commerce.”

In its second iteration business on the Net became more complex and specialized. Corporations began to appreciate the value of doing businesses with other enterprises, and to implement specialty business-to-business (B-to-B) e-Applications such as Maintenance, Repair, and Operations (MRO) procurement to automate simple online processes. On the business-to-consumer (B-to-C) side, retailers recognized the value of personalized content and dynamic product information. Online marketplaces became more interactive and efficient. “Bricks and mortar” had become “point and click.” Because this stage was about more than simple transactions, we labeled it “e-Business.”

Most companies have embraced e-Commerce by now. Some have taken halting steps toward e-Business. However, I predicted that another stage was coming, where corporations would recognize the Net for its true value: not a new distribution channel or customer touch-point, but a strategic tool that touches every aspect of the enterprise—both on the Net and in the real world, through process engineering, improvement, and integration.

Let's say you've absorbed all there is to be learned about developing the next successful e-Enterprise. Perhaps you've already moved your learning into the marketplace, and the results have been the best you could have hoped for.

What you have won is the right to compete again.

If there's a bottom-line lesson to everything we know about e-Enterprise, it is this: if you haven't created business and technology architectures that enable you to win and win again—if they aren't robust and repeatable in terms of producing success—then you haven't arrived at e-Enterprise yet.

The right tools in this environment are the ones that allow business leaders to replicate—even automate—business and technology analysis and decision making, iteration after iteration. How else can you stay abreast of market opportunities and ahead of your competitors in today's relentlessly competitive environment? As Tom Trainer, CIO of Citigroup, said in the Foreword, you have to think about business and technology architecture as “a repository of reusable strategic assets that allow your e-Enterprise to evolve as rapidly and continuously as today's fluid markets.” Only that, meshed with an organizational culture and people endlessly motivated to learn more and push ahead, offers an unbeatable combination.

It should be abundantly clear that this book has not been about telling you how to be the next Amazon.com. In fact, we believe that the glory days of the Net-only business model may be coming to an end.

In this chapter I will introduce a powerful proof technique based on mathematical induction. With it we will be able to prove complex and important properties of programs that cannot be accomplished with proof-by-calculation alone. The inductive proof method is one of the most powerful and common methods for proving program properties.

Induction and Recursion

Induction is very closely related to recursion. In fact, in certain contexts the terms are used interchangeably; in others, one is preferred over the other primarily for historical reasons. I like to think of them as being duals of each other: Induction is used to describe things starting with something very simple, and building up from there, whereas recursion describes the whole thing first, working backward to the simple case.

For example, although I have previously used the phrase recursive data type, in fact data types are often described inductively, such as a list:

On the other hand, we usually describe functions that manipulate lists, such as map and foldr, as being recursive. This is because when you apply a function such as map, you apply it initially to the whole list, and work backwards toward [ ]. But these differences between induction and recursion run no deeper: They are really just two sides of the same coin.

This chapter is about inductive properties of programs (but based on the above argument could just as rightly be called recursive properties) that are not usually proven via calculation alone. Proving inductive properties usually involves the inductive nature of data types and the recursive nature of functions defined on the data types.

As an example, suppose that P Is an inductixe property of a list. In other words, P(l) for some list l is either true or false (no middle ground here!), To prove this property inductively, we do so based un the length of the list: Starting with length 0, we first prove P([]), (using our standard method of proof-by-calculation).