The tt(EVAL) function takes one argument: the text to be evaluated. This
function allows you to perform an indirect evaluation of Yodl commands. Assume
that there is a symbol tt(varnam) containing the name of a counter variable,
then the following displays the counter's value, after having incremented it:
        verb(
    EVAL(NOTRANS(USECOUNTER)(SYMBOLVALUE(varnam)))
        )

    Here, tt(EVAL) performs the following steps:
    itemization(
    it() First, tt(NOTRANS(USECOUNTER)) is evaluated, producing
        tt(USECOUNTER).
    it() Next, the open parenthesis is processed, producing the open
        parenthesis itself
    it() Then, tt(SYMBOLVALUE(varnam)) is evaluated, producing the name of a
        counter, e.g. `tt(counter)'.
    it() The closing parentheis is processed, producing the closing
        parenthesis itself.
    it() All this results in the em(text)
        verb(
    USECOUNTER(counter)
        )
    it() This text is presented to Yodl's lexical scanner, resulting in
        incrementing the counter, and displaying its incremented value.
    )

    b(Caveat): macro arguments themselves are usually not evaluated. So, a
construction like
        verb(
    USECOUNTER(EVAL(SYMBOLVALUE(varnam)))
        )
    fails, as `tt(EVAL(SYMBOLVALUE(varnam)))' is not a legal name for a
counter. Here the tt(EVAL()) call is used as an argument, and is therefore not
expanded. 

    The distinction is subtle, and is a consequence of the fact that builtin
functions receive unprocessed arguments. Builtin functions may impose certain
requirements on their arguments (like tt(USECOUNTER) requiring the name of a
counter) and these requirements are checked on the arguments as received.

    Summarizing: tt(EVAL) acts as follows:
    itemization(
    it() Its argument is presented to Yodl's lexical scanner
    it() The output produced by the processing of the argument is then
inserted into the input stream em(in lieu of) the original tt(EVAL) call.
    )

    Most built-in functions do em(not) evaluate their arguments. In fact, only
tt(ERROR, EVAL, FPUTS, INTERNALINDEX, PUSHSUBST, TYPEOUT, UPPERCASE, WARNING)
and the iinternally used tt(XXSUBST) functions evaluate their arguments.

Postponing evaluations allows you to write:
        verb(
    DEFINESYMBOL(later)(SYMBOLVALUE(earlier))
        )
    Eventually, and not when tt(later) is defined, a statement like
        verb(
    SYMBOLVALUE(later)
        )
    produces the value of tt(earlier) at the moment tt(SYMBOLVALUE(later))
is processed. This is, in all its complex consequences, what would be expected
in most cases. It allows us to write general macros producing output that is
only evaluated when the text of symbols and values of arguments become
eventually, rather than when the macro is defined, available. 

    Decisions like these invariably result in questions like `what if I have
to define variables using values of other variables?' In those cases
tt(EVAL()) must be used. The following example shows the definition of three
symbols: tt(one) receives an initial value, tt(two) returns tt(one)'s actual
value when tt(two)'s value is displayed, tt(three), using tt(EVAL()), stores
tt(one)'s initial value.

    The example also shows yet another way to suppress macro calls, using the
macro tt(nop()) which is defined in the all standard conversion types:
        verb(
    DEFINESYMBOL(one)(One's first value)
    DEFINESYMBOL(two)(SYMBOLVALUE(one))
    EVAL(DEFINESYMBOL+nop()(three)(SYMBOLVALUE(one)))
    SETSYMBOL(one)(One's second value)
    "SYMBOLVALUE(two)"      COMMENT(displays "One's second value")
    "SYMBOLVALUE(three)"    COMMENT(displays "One's first value")
        )


