Part II: The AppleScript Language

Part II is the heart of the book; it describes the AppleScript programming language.

This part is intended for use both as a reference and as a source of instruction. The order of exposition is pedagogical , and the chapters are meant to be read in order.

The chapters are:

Chapter 4, Introducing the Language

Chapter 5, Syntactic Ground of Being

Chapter 6, A Map of the World

Chapter 7, Variables

Chapter 8, Script Objects

Chapter 9, Handlers

Chapter 10, Scope

Chapter 11, Objects

Chapter 12, References

Chapter 13, Datatypes

Chapter 14, Coercions

Chapter 15, Operators

Chapter 16, Global Properties

Chapter 17, Constants

Chapter 18, Commands

Chapter 19, Control

Chapter 4. Introducing the Language

Part I of this book describes AppleScript as a technology why and where and how you use it (Chapter 1 and Chapter 2), the Apple events that lie behind it, the AppleScript scripting component that implements it, the kinds of file it creates and some of the details of working with those files, and the means and modes whereby applications make themselves scriptable with it (Chapter 3). But AppleScript is also a language , a programming language that you'll want to learn and understand in order to create and edit AppleScript code on your own. Part II of this book teaches it to you.

This chapter serves as a starting point for your journey through the AppleScript language. The longest journey, it is said, begins with a single step. But even before that, sometimes it's a good idea to contemplate the road. That's what this chapter does. It describes the nature of the AppleScript language in very general terms. What sort of language is it? What is it like to learn and to use?

The AppleScript language deserves contemplation, and often gets it. AppleScript's users seem to spend as much time and energy venting their feelings about AppleScript as they do writing and editing AppleScript code. It's that kind of language. It frequently evokes an emotional reaction, and that emotion can range from frustration through exasperation to fury. Yet at the same time AppleScript has some surprisingly clever behaviors and abilities , and some remarkably sophisticated features.

I've never created a computer language, but I suspect it must be a special sort of labor, both satisfying and frustrating, a blend of artistry and engineering, calling for vision, philosophy, planning, determination, sweat, time, and sheer technological expertise. A computer is just a machine, but a computer language is a human creation. You might expect it to be dry, cold, and logical, but it isn't. Every computer language bears the stamp of its makers , and to learn a computer language is to experience, in some measure, the forces and ideas and goals that went into its creation. In short, AppleScript has a flavor. This chapter tries to describe that flavor.

(If you haven't read Appendix A, I would urge you to take a moment to do so right now. It displays, by actual example, what it's like to work with AppleScript, and shows why it's important to have a solid grounding in the language before trying to get any serious work done toward scripting a target application.)

4.1. A Little Language

The "little language" philosophy, as represented by such computer languages as LOGO, Smalltalk, and Scheme, comes in various forms but the very words "little language" tell you most of what you need to know. Littleness can be a virtue in a number of ways. A little computer language can fit in a small space and be run by a small interpreter. A little computer language can be easy to learn, just because there's less of it to learn. A computer language is a tool to make tools, so the initial tool itself can be quite minimal, provided it has the power to make any other tools that may prove necessary.

All of these notions apply to AppleScript. AppleScript was to be easy for users to learn, so the less there was of it, the better. AppleScript appeared at a time when the idea of a computer with as much as four megabytes of random-access memory still felt rather strange and extravagant. To minimize expenditure of time and space resources, it had to compile with just a single pass. In these days of hundreds of megabytes of RAM and dozens of processes running simultaneously , it's easy to forget that AppleScript comes from a day when running more than one application at once on your Macintosh was a relatively new experience, and liable to tax the computer's resources to the utmost. At the time, AppleScript itself needed to be small simply to stay out of the way of other applications. The first version of AppleScript could load a scripting component instance and run a heavily recursive script in less than 300K of RAM.

And the purpose of AppleScript, after all, was to tell other programs to do things. Thus AppleScript itself could afford to be so minimal as to have little or no power of its own. AppleScript has minimal string-munging and number- crunching facilities, but then AppleScript is not intended for munging strings or crunching numbersit's made for driving applications, and they can munge the strings and crunch the numbers if need be.

So is AppleScript's littleness a virtue? Probably notat least, not any more. Thanks to Moore's Law and the passage of time, we no longer need AppleScript to be so tiny. Its small size certainly makes it easier to learn than, say, Perl (a language so big and so full of options and functions it can make your head swim), but it is not an easy language at all; on the contrary, it's tricky and quirky and needs a big book like this one to explain it. And if you're used to a full-fledged scripting language, AppleScript comes as something of a disappointment. Perl, for example, has some hundreds of built-in functions; AppleScript has about a dozen , and seems to be missing some extremely basic functionality. Perl has built-in support for powerful string manipulation, regular expressions, and trigonometry; AppleScript doesn't. Just as you don't miss the water until the well runs dry, the "little language" philosophy seems very cute just until you actually need to get something done. On the other hand, if you don't try to misuse it, AppleScript seems quite adequate, especially since it can now (under Mac OS X) avail itself directly of the power of Perl and other built-in Unix tools. As I said in Chapter 1, success may be simply a question of combining specialities appropriately.