2.4. Delayed evaluation
Sometimes it is necessary to prevent Maple from evaluating a name or an expression that, because of the rule of full evaluation, would otherwise be evaluated. In this section we show that the rightquote character is used in Maple to prevent, or delay, evaluation. Here is a simple example of preventing the evaluation of a name. Let us give
x
a value.
In the next command Maple will evaluate
x
, because of the rule of full evaluation, and so the value of
y
becomes 6.
But suppose we had really wanted the value of
y
to be literally
x+3
. We can do this in the next command by putting a pair of singlequotes around
x
which prevent Maple from evaluating the
x
.
Notice from the command's output that
y
is now a name for
x+3
because
x
was not evaluated in the last command.
But the single quotes only prevented Maple from evaluating
x
in that one command. Look carefully at the last command's output. There are no rightquotes there. And so the next command will fully evaluate
y
to get 6, since the evaluation of
x
was only prevented in the command that defined
y
.
Using one level of evaluation we can verify that
y
is a name for
x+3
.
Another way to put this is that the definition of
y
is
not
an unevaluated
x
plus 3, the definition of
y
is simply
x
plus 3. For this reason, the rightquotes used in the definition of
y
are more properly referred to as
delayed evaluation
of
x
, and not as preventing the evaluation of
x
. Here is another simple example. The next command is an equation and the first
x
has its evaluation delayed and the second
x
is evaluated right away.
If we reevaluate the last output, the
x
in the output will get evaluated.
Now for a more subtle example. In the next command we have a doubly delayed evaluation of the first
x
and a singly delayed evaluation of the second
x
.
If we reevaluate the last output, the second
x
is evaluated but the first
x
still has its evaluation delayed.
And if we reevaluate this last output, then the remaining
x
is finally evaluated.
Here is another example that uses several levels of delayed evaluation.
Notice that the value of
x
is
''y''
and not
'''y'''
. Maple used up one level of evaluation when it evaluated the right hand side of the assignment operator.
The last few commands lead us to make the following rule for evaluating expressions containing single quotes.
Whenever Maple comes across an expression with single quotes around it, Maple just removes one pair of single quotes and it does not evaluate whatever was inside the quotes
. This has the effect of "delaying" until later the evaluation of the whatever the quotes surrounded.
Here is an interesting question. What should Maple return if now we ask it to evaluate
x
?
Notice that this is the same answer that we got above when we used two levels of evaluation. What if we try to force full evaluation of
x
by using
eval(x)
?
This is the same answer that we got above when we used three levels of evaluation, but it is not full evaluation, which above took four levels of evaluation. Let us analyze carefully the steps that lead to these results for evaluating the expressions
x
and
eval(x)
. When Maple is asked to evaluate
x
, it first gets
''y''
. The above rule for evaluating single quoted expressions tells Maple to remove one pair of quotes and then quit evaluating, and so the final result is
'y'
. When Maple is asked to evaluate the expression
eval(x)
, first Maple needs to evaluate the argument to the
eval
command so Maple evaluates
x
to
'y'
. After Maple has the value of the argument to
eval
, Maple calls
eval
with this argument, so Maple calls
eval('y')
. But
eval
applies the above evaluation rule for single quoted expressions and so it just removes one pair of quotes from
'y'
to get
y
and that is the final result.
A common misunderstanding with delayed evaluation is that it can prevent automatic simplifications. In the next example, the right quotes do not prevent the automatic simplification of
u+u
.
Another way to think about this last example is that it shows that automatic simplification is not the same thing as evaluation;
u+u
does not evaluate to
2*u
, it simplifies to
2*u
. Here is a slightly different version of this example.
The right quotes prevented the evaluation of
u
but not the simplification of
u+u
. In the next command,
u+u
is both simplified and evaluated, and we know now that the simplification is done before the evaluation.
Exercise
: The
rand
function, which is built into Maple, is a function that takes no arguments and returns a random integer. Explain why the following command does not return a random fraction.
Here is one last example of how single quotes might be used. The following is a very "safe" way to define
y
to be the general quadratic equation.
> 
y := 'a'*'x'^2+'b'*'x'+'c'=0;

In this definition of
y
, we did not have to worry about any preassigned values of
a
,
b
,
c
, and
x
, and we did not need to unassign those variables either, which may, for some reason, be an undesirable thing to do. There are times when it is necessary to be this safe about a definition.
Exercise
: Is there a simpler, yet just as "safe", way to define the same
y
as from the last example?
Exercise
: You should be aware by now that the following two commands together will produce an error message and you should be able to explain why.
Error, (in plot) invalid arguments
Explain the results of the following three commands.
> 
plot('x'^2, 'x'=5..5);

Error, (in plot) invalid arguments
One level of delayed evaluation is an often used trick in Maple. We will see several uses for it in this and later chapters. Even two or three levels of delayed evaluation is needed in some odd circumstances, as we will see.