Section 15.7. Parentheses

15.7. Parentheses

Parentheses may be used to determine the order of operations at runtime:

3 + 4 * 2 --

11

(3 + 4) * 2 --

14

Parentheses can also help determine the order of interpretation of vocabulary at compile time. Thus they can make the difference between successful compilation and failed compilation. For example, this compiles fine, because all the expressions are legal:

set r to random number
round r rounding up

Now try to save a line by combining them, and you get this ungrammatical and mysterious error:

round random number rounding up
--

compile-time error: A application constant [sic] or consideration can't
go after this identifier

The problem is that random number is a command that can optionally take various labeled parameters, and rounding up isn't one of them. Instead of rethinking its interpretation ("So, maybe random number isn't taking any parameters here!"), AppleScript just gives up. You have to help it out, by using parentheses:

round (random number) rounding up

Sometimes AppleScript will insert parentheses for you, on compilation. For example, I didn't put any parentheses when I typed this code:

tell application "System Events"
    copy name of every process where it is frontmost to theProc
end tell

But AppleScript did, when it compiled:

tell application "System Events"
    copy (name of every process where it is frontmost) to theProc
end tell

The reason seems to be to delimit a phrase implying a get command. But if you actually use get explicitly here without parentheses, AppleScript refuses to compile at all:

tell application "System Events"
    copy get name of every process where it is frontmost to theProc
    --

compile-time error: Expected "into", "to", etc. but found "get"

end tell

The problem seems to be that AppleScript doesn't like the phrase copy get , which is two commands in a row. If you add the parentheses, AppleScript compiles:

tell application "System Events"
    copy (get name of every process where it is frontmost) to theProc
end tell

Parentheses can also make a difference at runtime. AppleScript will compile this, but it causes an error at runtime:

tell application "System Events"
    set L to name of every process
    frontmost of process item 1 of L
    --

error: No result was returned from some part of this expression

end tell

This runs fine:

tell application "System Events"
    set L to name of every process
    frontmost of process (item 1 of L)
end tell

The moral is: if things don't seem to be working out, try playing with parentheses.

15.8. Who Performs an Operation

Some operations within an interapplication communications context can be performed by the target application rather than by AppleScript. There are two cases to consider. The operation may appear as a bare expression (for example, the condition in an if clause); I will call this a direct operation . Or, the operation may be part of a boolean test element specifier .

15.8.1. Direct Operations

According to Apple's documentation, if the first operand of a direct operation is a reference to an object of the target application, the target application should perform the operation. So, for example:

tell application "Finder"
    if name of folder 1 contains "e" then

The object name of folder 1 is a Finder object, so in this case, according to Apple, the Finder should perform the operation. However, experimentation shows that the Finder does not perform the operation; AppleScript does try to get it to do so, but the target application replies with an error indicating that it doesn't wish to perform that sort of operation. AppleScript thereupon adopts a new strategy: it asks the target application for the values in question, and performs the operation itself.

So, here's how that example really works. AppleScript starts by sending the Finder a single Apple event that means: "Please tell me whether the name of your folder 1 contains "e" ." The Finder replies with an error message. So then AppleScript tries the other strategy: it goes back to the Finder and sends it another Apple event that means: "Okay, never mind that, just tell me the name of your folder 1." The Finder complies, and now AppleScript looks, itself, to see whether the result contains "e" .

This approach seems wasteful, but it is wasteful only the first time. The second time the same sort of code is encountered , the AppleScript scripting component remembers that the Finder doesn't do this sort of operation, and skips the first step; it just asks the Finder for the value of the operand and does the operation itself.

In fact, I have not found any application that appears willing to perform direct operations when AppleScript asks it to! The entire matter is therefore moot. One can see, all the same, that the mechanism is a good idea. For example, there is no way to ask an application whether two references are references to the very same thing:

tell application "Finder"
    set f1 to folder 1
    set f2 to folder "Mannie"
    f1 = f2 --

false

end tell

These are in fact one and the same folder, and it would be really great if the Finder could tell us so. In order for this to happen, though, the Finder would have to perform the comparison, and it simply isn't going to. Similarly, in this code:

tell application "Finder"
    if name of folder 1 is name of folder 2 then

It would be efficient to be able to ask the Finder, with a single Apple event, to perform this comparison and report on the result. As it is, AppleScript ends up sending the Finder two Apple events (one asking for the name of folder 1, the second asking for the name of folder 2) and performing the comparison itself.

15.8.2. Boolean Test Element Specifiers

In a boolean test element specifier (see Chapter 11), the target application always performs the comparison itself. For example:

tell application "Finder"
    name of every folder whose name contains "E"
end tell

That is a single Apple event; the Apple event includes instructions to use contains "E" as the criterion for returning folder names , so the Finder must implement contains in order to obey.

Differences between an application's implementation of an operator and AppleScript's implementation can arise under these circumstances. This seems rather scary, but if the application is well-behaved, these differences should be minor. The primary case in point is the use of considering clauses. For example:

tell application "Finder"
    considering case
        name of every folder whose name contains "E"
    end considering
end tell
--

{"emptyFolder", "Test Me"}

The Finder gives the wrong answer; if you consider case, neither of these folder names contains "E" . The Finder is simply ignoring the considering clause. In fact, I don't know of any application that considers considering clauses in a string comparison. (See "String Considerations" in Chapter 19.)

The workaround in a situation like this is a two-step approach: fetch all the values and then have AppleScript perform the test itself. AppleScript does not implement boolean test element specifiers for lists, so the test must be performed as a loop:

tell application "Finder"
    set L to name of every folder
end tell
set L2 to {}
considering case
    repeat with aName in L
        if aName contains "E" then
            set end of L2 to contents of aName
        end if
    end repeat
end considering

After that, L2 contains the right answer. Fortunately, such an approach is not particularly expensive in this case; luckily, the Finder implements get name of every (see "Operations on Multiple References" in Chapter 11), and the test we perform in the loop doesn't involve sending any Apple events.