Programming Languages and Applied Logic

Summary

NET FOR BUSINESS?

Not only has the basis of computing changed, the basis of competition has changed too.

—Andrew S. Grove, Chairman, Intel

Let's start out by taking a moment to ask—and answer—the most obvious of “e” questions: why do companies that are already successful at selling their products via the more traditional distribution channels (retail locations, catalogs, television, and even the telephone) feel the need to sell their wares online? In short, what is the appeal of the Net?

First and foremost, the Net enables businesses to interact personally and directly with customers without incurring the overhead costs of building a larger sales force, opening new retail locations, or hiring and training new customer service representatives.

At first glance, this seems a bit absurd. How does the World Wide Web—largely just a repository of text and images—increase personal interaction? The answer lies in the capability of computers to gather, store, and transmit mountains of data in the blink of an eye. By always utilizing this information in real time, enterprises can focus on building personalized, long-term relationships with each and every customer, such as was done before the days of strip malls, superstores, and direct-mail catalogs. In many ways, this is a better way to do business. Let's pick a simple example to illustrate.

Say you want to read A Tale of Two Cities. Today, you'd probably just head down to the local branch of a national bookselling chain and buy a copy.

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

Our goal is not to be a visionary, but to get people to take advantage of what technology is available today.

—Scott McNealy, Chairman & CEO, Sun Microsystems

We want everybody who works on the Internet to think of Internet Explorer technologies as a platform that they can build on, a platform that they can take advantage of.

—Bill Gates, Chairman & CEO, Microsoft

If you listen to Scott and Bill, all you have to do is to choose between Sun and Microsoft to define your e-Enterprise software infrastructure. I wish the answer was that simple. Au contraire, thanks to the IT industry, choices are unlimited and go far beyond Sun, Microsoft, and Oracle. As a matter of fact, choosing the right implementation strategy from the vast architectural and vendor options is becoming increasingly difficult.

In Chapter 6, I have outlined a high-level, logical technology architecture that contains high levels of abstractions such as e-Application Rules, e-Application Distribution/Integration, e-Data, and e-Networks. In Chapter 7, you learned the driving business components that primarily define the reusable e-Application Rules. In this final chapter, I will introduce some of the emerging technology components that should be utilized to implement these higher-level abstraction layers from a pure technology perspective.

Although this chapter discusses a few selected emerging technologies, it is not intended to be a recipe for physical implementation. Rather, it is intended to explore important standard technologies that should be understood, considered, independently verified, and validated for each e-Initiative.

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

I don't think there's been anything more important or more widespread.… Where does the Internet rank in priority? It's No. 1, 2, 3, and 4.

—Jack Welch, Chairman & CEO, General Electric

When Jack Welch makes the Net his top business priority you can be sure that the Internet and Net-based business have taken the critical step from possibility into reality. In fact, General Electric and countless other Global 2000 companies are quickly investigating and applying the newest Internet technologies. These companies seek to gain and retain competitive advantages in new and evolving markets through highly adaptive Net-based enterprises. Everywhere you turn, both the mainstream and business news media are focused on the Net Revolution. Both alluring and critical reports about the Web, the Information Superhighway, and Internet ventures abound.

The Net is the backbone for the new digital economy that is radically changing business models around the globe. These new business models have become differentiators that redefine market winners and losers. No one is safe from the changing tide. Past critics of the Internet have said that it's a gadget for hobbyists and computer geeks—not a valuable tool for business. It's all hype, they said. As evidence they pointed to the astronomic market capitalization of so-called Internet stocks. They said that conventional enterprises are safe from these over-publicized startups. Put simply, they were wrong then, and they're wrong now. As Business Week says “You are Merrill Lynch when Schwab.com comes along.

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

Whoever invented the button didn't need much of a business architecture model to cope with the change he unleashed. The button, a thirteenth-century invention, took 400 years to achieve widespread use. The bicycle appeared in 1818 and took 50 years to catch on. The telephone, invented in 1876, needed 35 years to find the beginnings of a mass market. Television took 26 years; the personal computer, 16 years.

Those adoption rates seem pretty leisurely by today's standards. The unyielding environment of speed in technology-induced business change is so pervasive that a CEO (or any C*O, responsible for operations, finance, human resources, technology, marketing, or any other function) who doesn't occasionally get a sense of panic perhaps doesn't get a lot of other things either.

And speed is only one element of the profound paradigm shift that is happening in how business is transacted as a result of the Internet. The e-Revolution is on and—as is the tendency of revolutions—things can be a bit confusing while the participants sort themselves out.

Maybe it was acceptable that your company created its first Web site to “keep up with the Joneses”—whoever they are in your industry. You didn't need much of a model or architecture for that decision; the Joneses, after all, were equally unsure about what they were doing and why. Maybe you made your first forays into electronic commerce and electronic business in the same fashion.

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

Summary

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.

module Robot where

import Array

import List

import Monad

import SOEGraphics

Import Win32Misc (timeGetTime)

import qualified GraphicsWindows as GW (getEvent)

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.

Summary

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 ⇒ ….

Programming Languages and Applied Logic

Refine search

Refine search

Actions for selected content:

5644 results in Programming Languages and Applied Logic

Chapter 2 - e-Application Models

Summary

14 - Programming With Streams

Summary

Chapter 8 - e-Enterprise Technology Components

Summary

9 - More About Higher-Order Functions

Summary

23 - A Tour of the Preludelist Module

Summary

21 - Interpreting Functional Music

Summary

2 - A Module of Shapes: Part I

Summary

Dedication

PART 4 - Enabling Components

Chapter 1 - From Net Commerce to e-Enterprise

Summary

10 - Drawing Regions

Summary

Acknowledgments

24 - A Tour of Haskell's Standard Type Classes

B - Pattern-Matching Details

Summary

Foreword

Summary

1 - Problem Solving, Programming, and Calculation

Summary

19 - An Imperative Robot Language

Summary

References

PART 1 - The e-Enterprise

12 - Qualified Types

Summary

Programming Languages and Applied Logic

Refine search

Refine search

Actions for selected content:

Save Search

5644 results in Programming Languages and Applied Logic

Summary

Summary

Summary

Summary

Summary

Summary

Summary

Summary

Summary

Summary

Summary

Summary

Summary

Summary