1999 + 1 // Yields the datum 2000
"hi " + "ma!" // Yields the datum "hi ma!"
firstName // Yields the value of the variable *firstName*
_currentframe // Yields the frame number of the playhead's current position
new Date( ) // Yields a new *Date* object with the current date and time

Notice that an individual literal expression like 1999 or 1 can be a
valid part of a larger complex expression, as in *1999 +
1*.

Whether we use a literal expression or a complex expression to create
data, we must store every datum that we want to use later. The result
of the expression `"hi" + "ma!"` is lost unless we
store it, say, in a variable. For example:

// This datum is fleeting, and dies immediately after it's created
"hi " + "ma";
// This datum is stored in a variable and can be
// accessed later via the variable *welcomeMessage*
var welcomeMessage = "hi " + "ma";

### 3.3.2. Automatic Complex Expression Typing

The
interpreter computes an
expression's value in order to determine its datatype. Consider
this example:

pointerX = _xmouse;

Because `_xmouse` stores the location of the mouse
pointer as a number, the type of the expression
`_xmouse` will always be a number, so the variable
`pointerX` also becomes a number.

Usually, the datatype automatically determined by the interpreter
matches what we expect and want. However, some ambiguous cases
require us to understand the rules that the interpreter uses to
determine an expression's datatype (see Example 2-2 and Example 2-3). Consider
the following expression:

"1" + 2;

The operand on the left of the `+` is a string
("1"), but the operand on the right is a number (2). The
`+` operator works on both numbers (addition) and
strings (concatenation). Should the value of the expression
*"1" + 2* be the number 3, or the string
"12"? To resolve the ambiguity, the interpreter relies on
a fixed rule: the plus operator (`+`) always favors
strings over numbers, so the expression *"1" + 2*
evaluates to the string "12", not the number 3. This rule
is arbitrary, but it provides a consistent way to interpret the code.
The rule was chosen with typical uses of the plus operator in mind:
if one of the operands is a string, it's likely that we want to
concatenate the operands, not add them numerically, as in this case:

trace ("The value of x is: " + x);

Combining disparate types of data or using a datum in a context that
does not match the expected datatype causes ambiguity. This forces
the interpreter to perform an automatic datatype
*conversion* according to arbitrary, but
predictable, rules. Let's examine the cases in which automatic
conversions will occur and what the expected results are of
converting a datum from one type to another.