Section 19.2. Looping

The other major form of choice is looping , which involves branching back to the start of a block repeatedly. In AppleScript, looping is performed with repeat. There are several varieties of repeat, but repeat blocks all take same basic form:

Loops involve repetitionperhaps a lot of repetition. Therefore, although I'm no great believer in worrying too much about optimization, if you're going to optimize your code anywhere, loops are the place to do it. A small increase in speed can add up tremendously over multiple repetitions. See Chapter 22.

The big question with a repeat block is how you're going to get out of it. Obviously you don't want to repeat the repeat block forever , because that would be an infinite loop and would cause the computer to hang. Most kinds of repeat block include some instruction (as symbolized by whatKindOfRepeat in the syntax template), such as a condition to be evaluated, as a way of deciding whether to loop again.

There are also some special commands for hustling things along by leaping completely out of the repeat block from inside it. These are the premature terminations of a repeat block. They can be used with any form of repeat block. Here they are:

19.2.1. Repeat Forever

A repeat block with no whatKindOfRepeat condition repeats forever. Obviously you don't really want it to repeat forever, so it's up to you to supply a way out by using one of the three premature terminations.

19.2.2. Repeat N Times

A repeat block where whatKindOfRepeat is an integer followed by the keyword times repeats that number of times (unless the block terminates prematurely). The integer can be a variable.

An interesting misuse of this construct is as a workaround for AppleScript's lack of a next repeat or continue keyword. (This idea was suggested to me by Paul Berkowitz, who attributes it to Ray Robertson.) The problem is that you can short-circuit a repeat block by exiting it completely, but you cannot, as you can in many languages, short-circuit it by proceeding immediately to the next iteration of the loop. The workaround is to embed a one-time repeat block within your repeat block; an exit repeat within this one-time repeat block works as a next repeat with respect to the outer repeat block. This device has some shortcomings (it prevents exit repeat from doing its proper job), and it doesn't accomplish anything you couldn't manage with an if block, but in a large script it can make your code easier to read and maintain.

19.2.3. Repeat While

A repeat block where whatKindOfRepeat is the keyword while followed by a boolean condition tests the condition before each repetition. If the condition is true, the block is executed. If the condition is false, the block is not executed and that's the end of the loop; execution resumes after the end repeat line. The idea is that in the course of looping something will eventually happen that will make the condition false.

19.2.4. Repeat Until

A repeat block where whatKindOfRepeat is the keyword until followed by a boolean condition tests the condition before each repetition. If the condition is false, the block is executed. If the condition is true, the block is not executed and that's the end of the loop; execution resumes after the end repeat line. This construct is technically unnecessary, as the very same thing could have been achieved by reversing the truth value of the condition of a repeat while blockthat is to say, repeat until is exactly the same as repeat while not.

Those accustomed to the do...until construct in C and similar languages should observe that it is possible for an AppleScript repeat until block not to be executed even once.

19.2.5. Repeat With

When the repeat with announcement line is encountered for the first time, startInteger and endInteger (and stepInteger, if supplied) are evaluated once and for all. Each must be an integer (or a real or string representing an integer); if not, there's a runtime error.
If startInteger is larger than endInteger (or smaller if stepInteger is negative), that's the end of the loop and execution resumes after the end repeat line.
The value startInteger is assigned to the variable variableName, which is created as a local if not in scope already. (Note that variableName, if declared implicitly at the top level, will not be a global; this contradicts "Scope of Undeclared Variables" in Chapter 10.)
The block is executed. (If code within the block terminates the repetition prematurely, that's the end.)
The value 1 (or stepInteger if supplied) is added to the value that variableName was assigned before the previous repetition. If the resulting value is larger than endInteger (or smaller if stepInteger is negative), that's the end of the loop and execution resumes after the end repeat line. Otherwise, variableName is assigned this new value, and it's back to step 4 for another execution of the block.

19.2.6. Repeat With... In

This construct is a convenient way of cycling through each item of a list. Here's how to visualize the way it works:

The variable variableName is created as a local if it is not already in scope.
The size of the list is obtained. Call this number theCount.
A reference to the list is obtained. Call this theListRef.
A counter is initialized to zero. Call it x.
Before each repetition, x is incremented. If x exceeds theCount, that's the end of the loop, and execution resumes after the end repeat line. Otherwise, variableName is assigned this value:
```
a reference to item x of theListRef
```
The block is executed.

(In this sequence of steps, none of the variable names are real: there is nothing called theCount, theListRef, or x. But AppleScript is truly maintaining these values internally; I gave them names simply for clarity.)

The big surprise here is step 5, which sets the value of variableName. At the start of each repetition, nothing is copied from the list into variableName. It's a reference (see Chapter 12). So, for example, in this loop:

the variable x does not take on the values 1, 2, 3. It takes on these successive values:

References are often transparently dereferenced, so the fact that variableName is a reference might not make a difference to your code. For example:

In that example, the reference is implicitly dereferenced, and the value of each item is retrieved from the list. But consider what happens when the reference is not implicitly dereferenced. For instance, you might apply to variableName the equality or inequality operator:

The dialog never appears! That's because x is never 2. The second time through the loop, x is a reference to item 2 of {1, 2, 3}; that's not the same thing as the integer 2, and AppleScript doesn't implicitly dereference the reference. Clearly your script will misbehave if you're unprepared. The solution is to dereference explicitly:

What do you think L2 is after that? If you said {1, 2, 3}, you're wrong; it's this:

L1 is a list of values; L2 is a list of references. If you want L2 to end up identical to L1, you must dereference each reference:

A powerful consequence of the fact that variableName is a reference to an item of a list is that you can use it to assign back into the original list:

We can take advantage of this technique to rewrite the return-by-reference example from the end of Chapter 12 in a different way:

On the whole, you should probably not make more radical alterations to the list during the course of a repetition, but it is not unsafe to do so. If you assign a completely new value to the list variable, there is no change in the behavior of the loop, because a reference to the old list was already captured at the outset (that is the significance of the listRef variable in my explanation of how this construct works). So:

Why does that work? It's because on each repetition, x takes on these values, just as before:

You changed what L points to, but listRef already holds a reference to the original list. On the other hand, if you mutate the list in place, listRef is still a reference to that same list, so it acquires the mutations:

The dialog says "1" every time because, for example, by the time we come to the third loop and get a reference to item 3 of L, item 3 of L is 1. Observe that this code did not cause an infinite loop. That is the significance of step 2 in my explanation of how this construct works: theCount was evaluated once, before the first repetition, and you won't repeat more times than that.

A very odd thing happens when you combine repeat with...in directly with a class name as a way of gathering a list of elements, like this:

I've got only six folders on my desktop, so where did the number 50 come from? To put it another way, what did we just cycle through? The answer is that we didn't cycle through each folder; we cycled through each item inside each folder. (So 50 is the total number of files and folders inside the six folders on my desktop.) Here's why. When you talk like this, AppleScript does not ask the target application for a list of all the things you specify. Instead, it merely asks the target application for a count of those things. And it asks for this count in a very strange form:

Most applications simply shrug off this extra "each item"; most of their classes don't have an element called item, so they ignore this part of the command. For example, when you say this:

AppleScript asks Entourage to "count every contact each item." Entourage contacts don't have an item element, so Entourage treats this as if it were "count every contact" and simply reports the number of contacts. But in the Finder, a folder does have items, so the Finder obligingly totals up the number of items within each folder and reports that total.

This is not, however, simply an odd behavior on the part of the Finder; my point is what AppleScript does. We've just seen that when you say this:

AppleScript does not gather a list. It merely obtains a number. So how on earth does it perform the loop? In other words, what is x every time through the loop? When you say this:

And so on. AppleScript uses the class you asked for to form a reference to a particular item of the list that would be generated if we actually asked for it. But it doesn't ask for that list unless you try to fetch that item. This looks at first blush like an optimization, but if you think about, it's really quite the opposite. Consider what happens when you run this script:

That is already a wasteful script, as you could have obtained the names of all contacts with a single Apple event by asking for "name of every contact." But it's even more wasteful than you might suppose. Each time through the loop, you are not asking for "name of contact 1," "name of contact 2," and so forth. You are asking for "name of item 1 of every contact," "name of item 2 of every contact," and so forth. In other words, you are asking Entourage to form a list of all contacts, every time through the loop! That's unnecessary, because the list doesn't change.

This situation gets even worse if the list you're asking for is to be generated in a more complicated way. Here is some code where we try to get BBEdit to change all words that start with "t" to the word "howdy":

There are two problems with this code. First, it's incredibly wasteful, because every time through the loop, w is something like this:

Thus, if we do anything with w, we are asking BBEdit to perform this complicated boolean test (every word of window 1 where its text begins with "t") every time through the loop!

The second problem is that the code doesn't work. If there are two words starting with "t" in the document, it fails with a runtime error. The reason is that the second time through the loop, we are asking for this:

But there is no such item, because there were originally two such words and we just changed one of them to "howdy," so now there is only one such word.

The solution to this entire issue is: Don't Do That. Simply don't talk like this:

AppleScript's response to this way of talking may have been intended as an optimization, but it's just a mess. The simple solution is to gather the list explicitly, in the same line or an earlier line. So, say this:

All the problems with repeat with...in vanish in a puff of smoke if you do this. You ask for the list just once, at the start of the loop. That's the only time the application has to form the list, so execution is far less wasteful. You actually obtain the list you ask for, so you're looping through what you think you're looping through. So, for instance, this works properly:

And here's a quick, efficient, and correctly working version of our BBEdit script: