6.2 Result

At runtime, every line of AppleScript code that actually executes an expression—that is, it isn't blank, a comment, or mere flow control (looping and branching)—generates a result. This result is some sort of value; the particular value depends upon what the line does and what values it does it with.

The line need not be a "complete sentence"; any valid AppleScript expression constitutes a valid line, even if it does nothing (that is, even if it doesn't have what a computer science person would call "side effects"). For example, this is a valid line of AppleScript code, and it has a value (can you guess what it is?):

5

A line's result may be captured in two ways: explicitly or implicitly.

6.2.1 Explicit Result

The result of a line after it is executed may be captured explicitly by using the keyword result in the next line that is executed. For example:

5
display dialog result -- 5

One sees this technique used typically after fetching a value in a context of interapplication communication. For example, this is a fairly common style of coding:

tell application "Finder"
        get the name of every folder
end tell
set L to the result

Here's another example:

tell application "Finder"
        count folders
end tell
set c to the result

The reason why people use this technique appears to be twofold. First, it may be a habit left over from HyperTalk, where this sort of thing was pretty much standard practice. Second, there seems to be a sense that a line is more legible and understandable if it consists of a single command. This technique is never actually necessary, though. If you want to capture the result of a command, you can do it in the same line:

tell application "Finder"
        set L to (get the name of every folder)
        set c to count folders
end tell

Furthermore, there is an argument to be made that use of result is a bad idea, since you may not know what it represents as well as you think you do. For example:

set L to {"Mannie", "Moe"}
set end of L to "Jack"

After these two lines, L is {"Mannie", "Moe", "Jack"}, but result is "Jack". If you were expecting result to be the same as L, you'll be wrong, and code that depends upon this assumption won't work. That's a simple example; for more complicated code, the chances increase that you may be mistaken about what result represents. The problem is simply that you are dependent upon AppleScript's rules about what a statement's result is. But there is no need to be dependent upon these, or even to bother knowing what result a line generates, because it is never necessary to use result.

Also, result is volatile. It changes after the execution of every expression. If you get into the bad habit of not capturing values when they are generated, because you intend to pick them up later using result, you are just asking for trouble when another expression is executed in the meantime and the value you needed has been lost. This can easily happen, because you might insert a line in the course of developing your code; this kind of mistake is very difficult to debug.

6.2.2 Implicit Result

The result of a line's execution is captured implicitly if it is the last line executed in a handler or script. This means that in theory there is no need to return a value explicitly from a handler or script using return. For example, instead of this:

on add(x, y)
        return x + y
end add
display dialog add(1, 2)

it is possible to say this:

on add(x, y)
        x + y
end add
display dialog add(1, 2)

This technique suffers from the same drawbacks as using result. The keyword return has the great advantage that you know exactly what you're returning (because that's the value of whatever follows the word return) and when you're returning it (because the handler exits the moment return is encountered). To rely on an implicit result is to know neither of these things. A line's result, as we've seen, may not be what you think it is. And the value returned by a handler or script is not the value of its physical last line, but rather the value of whatever line happens to be executed last; where there is flow control (loops and branches), you might not know what line this will be.

In actual fact, I do tend to use the implicit result in one particular context—when developing or testing a script. A script editing program always displays the result after executing a script. Thus you can see whether the script is working as expected, by specifying the final result:

on add(x, y)
        x + y
end add
set z to add(1, 2)
z

The last line here is just a way of causing the value of z to show up as the result of the script after execution, to make sure it's being set as expected. Here it may be argued that the use of the implicit result is actually the best approach, and here's why. Suppose you return the result explicitly, like this:

on add(x, y)
        x + y
end add
set z to add(1, 2)
return z

You now proceed with developing the script, adding code after this snippet, and are very surprised when it doesn't work as expected. The reason is that you've accidentally left this line in the script:

return z

When that line is encountered, execution terminates; the code that follows it is never executed. You might think this sort of mistake unlikely, but I speak from extensive experience. By contrast, the nice thing about this line:

z

is that it has no effect at all on the behavior of your script, even if subsequent code is added later.