eval

eval, a built-in Tcl command, interprets its arguments as a script, which it then evaluates.

Synopsis edit

: eval arg ?arg ...?

Documentation edit

official reference

Description edit

eval concatenates its arguments in the same fashion as concat, and hands them to the interpreter to be evaluated as a Tcl script in the scope of the caller of eval. It then returns the result of that evaluation or any error generated by it.

eval is an old, old command that's been in Tcl from the beginning.

eval is useful when one wishes to generate a script and then interpret it.

In modern Tcl, eval is merely an abbreviation for uplevel 0. This is reminiscent of code-data duality, such languages as Lisp and Forth, self-modifying programs, and related esoterica.

if 1 ..., which may be byte-compiled, is an efficient replacement for eval in all cases. eval itself may also be byte-compiled if it is given only one argument which is a literal string.

To avoid the caveats of eval the rule of thumb is to pass only one argument to eval. Passing a single script rather than relying on implicit concatenation helps to avoid dumb mistakes such as passing a string which contains newlines. Also, when there is only one argument, and that argument is a pure list, eval can avoid generating any string representation for the value (tcl objc type: args uses only string of own type

, comp.lang.tcl, 2002-06-19).

Because the script is evaluated in the scope of the caller of eval a terminating command like return will cause the caller of eval to return.

eval is used by all the commands -- bind, everything with -command, and so on -- that receive scripts as arguments.

When using eval, it is very easy to leave holes which can be exploited to inject malicious code, so it is best to exercise extreme care with it until one learns the ropes.

eval can often be avoided, particularly with more modern recent versions of Tcl.

Eval and double substitution edit

eval is one of the Tcl constructs that causes the Tcl interpreter to scan over its arguments another time and evaluate what it scans.

Given the following assignment,

set b {the total is $20}

each of the following commands returns a is different result:

set a $b
eval {set a $b}
eval "set a $b"
eval [list set a $b]

Consider the first one,

set a $b

Prior to invoking set, Tcl performs its substitutions, so the command becomes

set a {the total is $20}

set receives the arguments a, and the total is $20, does not perform any internal parsing or substitution on its own, and sets the value of $a to the total is $20.

In the second one,

eval {set a $b}

Tcl does not perform any substitutions on the value in curly brackets, so the command remains unchanged. eval receives one argument,

set a $b

which it then hands back to the interpreter. This time the interpreter sees set a $b, which becomes:

set a {the total is $20}

so the value of $a becomes the total is $20.

In the third example,

eval "set a $b"

Tcl changes the command to

eval {set a the total is $20}

eval receives the argument

set a the total is $20

and hands it to the interpreter for evaluation. This time, the interpreter sees

set a the total is $20

fails to find the variable $20 and raises an error. If there had been no variable error, the interpreter would have invoked set with too many arguments, causing set to raise an error.

eval [list set a $b]

Tcl changes the command to eval {set a {the total is $20}}, set receives the arguments a {the total is $20}, and the value of $a becomes the total is $20.

See double substitution for the details of why it can be dangerous.

Is eval Evil? edit

Short answer: No. Like many commands in Tcl, eval can lead to double substitution. Sometimes this is desirable, and sometimes it isn't. The skilled Tcl programmer knows how to wield double substitution.

Historically, eval was often used with exec, to flatten lists, allowing a single list to provide multiple arguments to a command:

#warning: no-longer recommended
eval exec grep foo $filelist

because otherwise grep would receive filelist as one long filename with embedded blanks.

In modern Tcl, the following is preferred for reasons of efficiency and safety:

exec grep foo {*}$filelist

Or, if you want to append one list's elements to another, and you're willing to assume that the variable containing the new elements doesn't embed any unquoted semicolons or newlines:

eval lappend thislist $thatlist

Though the following two options are safer and faster:

set thislist [concat $thislist $thatlist] ;# Tcl 8.4
lappend thislist {*}$thatlist             ;# Tcl 8.5+

Another application is in building up a script in pieces (by appending to a string) and finally calling

eval $script

When the script contains only one command, argument expansion is preferred:

{*}$cmd

Expanding Lists with eval edit

Prior to Tcl version 8.5, one use case for eval was to expand lists. There is no longer any reason to do this. Use {*} instead.

See Argument expansion.

Instead of:

#warning: not recommended
eval pack [winfo children .]

use:

pack {*}[winfo children .]

And instead of:

#warning: this is not recommended
set filepath [list path to the file]
eval file join $filepath

use:

set filepath [list path to the file]
file join {*}$filepath

Another similar example

#the old (bad) way
set f [glob *.tcl]
eval [linsert $f 0 exec lp]

#the shiny new way
exec lp {*}$f

Historical

The following describes the situation before the advent of {*}:

Naive code might look like this (an actual example from BWidget's entry.tcl:97):

#warning: bad code ahead!
eval entry $path $maps(:cmd)

An unsuccessful attempt to fix the problem:

#warning: bad code ahead!
eval entry [list $path] $maps(:cmd)

But $maps(:cmd) might be a string with newlines:

set maps(:cmd) {
    -opt1 val1
    -opt2 val2
}

It's necessary to first convert $maps(:cmd) to a proper list using one of the list commands:

eval [linsert $maps(:cmd) 0 entry $path]

Caveat: List-Like Strings edit

The arguments to eval are concatenated into a string to be interpreted, but this operation does not guarantee that the string will be a well-formed script (i.e., one conforming to the Tcl parsing rules as laid out in the Tcl manual page).

The following script breaks because the concatenation keeps the newlines from the list's string representation, making eval interpret the second element as a new command:

% set arg {a
b
c
}
a
b
c
% eval list $arg
ambiguous command name "b": bgerror binary break

To solve this, construct the argument using list primitives like lappend, list, etc. DKF says: "list and eval are truly made for each other."

Another solution is to use the following idiom:

% eval [linsert $arg 0 list]
a b c

linsert converts its list argument to a well-formed list with single spaces separating elements, and then inserts further elements into it (if any of these elements contain newlines, they remain in the resulting string).

It's important to remember that eval works on strings, not lists, and the rules for interpreting a string as a list are different than the rules for interpreting a string as a script.

Verbose Evaluation edit

LV: I just had to copy this over to the wiki - it is so neat!

From comp.lang.tcl, Bob Techentin writes in response to a poster:

It sounds like you're looking for something similar to /bin/sh "set -v" command which prints shell input lines as they are read, and "set -x" which prints expanded commands. Kind of like a verbose mode.

Nope. Nothing like that. But you wouldn't have to write your own shell. You could walk through a script (a list of lines), and use info complete to decide how many lines are required to complete the command, then print both the command and the command's results. This seems to work.

proc verbose_eval {script} {
    set cmd {} 
    foreach line [split $script \n] {
    if {$line eq {}} {continue}
        append cmd $line\n
        if {[info complete $cmd]} {
            puts -nonewline $cmd
            puts -nonewline [uplevel 1 $cmd]
            set cmd ""
        }
    }
}

set script {
    puts hello
    expr {2.2 * 3}
}

verbose_eval $script

LV: This proc is so slick! I love it!

Lars H: Another approach to this (which also can see individual commands in if branches, loop bodies, etc.) is to use traces. Do we have that written down anywhere?

AR Here is my proposal with traces. Rem: the "noop" string is some kind of magic cookie.

proc eval_verbose {Script} {
    uplevel 1 "\# noop\n$Script"
}
proc eval_verbose_trace {command-string op} {
    if {![string match {uplevel 1 \{\# noop*} ${command-string}]} {
            puts "# ${command-string}"
    }
}
trace add execution eval_verbose enterstep eval_verbose_trace

eval_verbose {
    pwd
    puts A
    expr 12*3
}

PYK 2014-05-10: See also Scripted List, which does something similar.

Evaluating Code in a Scoped Manner edit

[wtracy] 2008-06-23: I want the commands I run in eval to have their own set of variables independently of the calling script. Is there some way I can hand eval a context (maybe as an associative array?).

Lars H: Sounds like you want a lambda (or possibly a closure, which is more difficult). If you're using Tcl 8.5, then have a look at apply.

RS: Long before 8.5, you could always write a little proc to hide its local variables (x in this example):

% eval {proc {} x {expr {$x*$x}}; {} 5}
25

[wtracy]: Thanks. It looks like apply is the closest Tcl feature to what I want.

[wtracy]: Actually, it looks like what I *really* want is to nest eval inside of a namespace eval block.

[wtracy]: Okay, for the sake of any lost soul that comes along after me, this is what I really wanted to do all along:

$ set cmd {puts FOO}
puts FOO
$ namespace eval MyNameSpace $cmd
FOO

NEM: As mentioned, apply is probably a better choice in this case as it is less surprising wrt. variables. See dangers of creative writing for some related discussion. The apply version is:

apply {{} {puts FOO} ::MyNameSpace}

This has the benefit of evaluating the code within a fresh procedure context, meaning all variables are local

to that context by default. See also namespace inscope/namespace code and you may also like dict with.

Proposal: Modify eval to Accept a List of Lists edit

In some cases eval does work on lists - and its special. In particular, if eval is passed a pure list then it gets evaluated directly, without another round of substitution. However, I think the utility is just short of what it could be.

When you pass eval a pure list, you can only execute a single command. What if we were to pass eval a list of pure lists - it should directly evaluate each of them, and return the value of the the last one evaluated. This sounds a lot like progn in lisp, and it seems like it would allow for some nifty bits of introspection - for example, if info body returned a pure list of lists rather than a string, that could be evaluated directly. Or modified. The whole program becomes a list of lists.

The problem is how to signal to eval (or uplevel, namespace, bind, ...) that it is a list of lists rather than just a list. Could eval determine if its input is a pure list and the first argument of that is a pure list, then evaluate as progn?

Another place this seems like it could be useful: I have a pkgIndex.tcl file with the line

package ifneeded tls 1.4 [
    list load [file join $dir libtls1.4.so]];[
    list source [file join $dir tls.tcl]]

where most of the lines are like

package ifneeded tclperl 2.3 [list load [file join $dir tclperl.so]]

since they only need one command; but the tls line needs two commands. So why can't it be

package ifneeded tls 1.4 [list [
    list load [file join $dir libtls1.4.so]] [
    list source [file join $dir tls.tcl]]]

Progn edit

RS 2004-02-06: As usual in Tcl, functionality you miss you can easy roll yourself. I needed a progn-like list eval in RPN again, and did it similar to this:

proc leval args {
    foreach arg $args {
        set res [uplevel 1 $arg]
    }
    set res ;# return last ("n-th") result, as Tcl evaluation does
}

eval versus bytecode edit

AMG: It appears eval'ed code does not get bytecode-compiled, even when eval is passed a single brace-quoted argument. The same is true for uplevel 0 and time. catch and if 1 seem to be bytecoded. {*} also gets bytecoded, but it doesn't accept a script "argument", rather a single command line pre-chewed into an objv list. Bytecoding cannot take place when the argument is the product of list, since the script isn't in a permanent Tcl_Obj.

proc a {} {eval           {for {set i 0} {$i < 100000} {incr i} {}}}
proc b {} {uplevel 0      {for {set i 0} {$i < 100000} {incr i} {}}}
proc c {} {time           {for {set i 0} {$i < 100000} {incr i} {}}}
proc d {} {catch          {for {set i 0} {$i < 100000} {incr i} {}}}
proc e {} {if {1}         {for {set i 0} {$i < 100000} {incr i} {}}}
proc f {} {            {*}{for {set i 0} {$i < 100000} {incr i} {}}}
proc g {} {eval      [list for {set i 0} {$i < 100000} {incr i} {}]}
proc h {} {uplevel 0 [list for {set i 0} {$i < 100000} {incr i} {}]}
proc i {} {time      [list for {set i 0} {$i < 100000} {incr i} {}]}
proc j {} {catch     [list for {set i 0} {$i < 100000} {incr i} {}]}
proc k {} {if {1}    [list for {set i 0} {$i < 100000} {incr i} {}]}
proc l {} {       {*}[list for {set i 0} {$i < 100000} {incr i} {}]}
proc m {} {try            {for {set i 0} {$i < 100000} {incr i} {}}}
a;b;c;d;e;f;g;h;i;j;k;l;m
time a 10    ;#  80723.8 microseconds per iteration - slow
time b 10    ;#  65380.2 microseconds per iteration - slow
time c 10    ;#  66024.8 microseconds per iteration - slow
time d 100   ;#  18888.3 microseconds per iteration - fast
time e 100   ;#  18779.3 microseconds per iteration - fast
time f 100   ;#  19375.2 microseconds per iteration - fast
time g 10    ;# 319111.5 microseconds per iteration - very slow
time h 10    ;# 342878.4 microseconds per iteration - very slow
time i 10    ;# 322279.2 microseconds per iteration - very slow
time j 10    ;# 316939.0 microseconds per iteration - very slow
time k 10    ;# 321865.5 microseconds per iteration - very slow
time l 10    ;# 344009.5 microseconds per iteration - very slow
time m 100   ;#  19503.0 microseconds per iteration - fast

I want single-argument eval functionality in my code, but I also want bytecoding. catch has the undesirable side effect of hiding errors, so I guess I have to use if 1 ... which is a really weird idiom. Does anyone have any better ideas?

AMG: I reran the tests and got better numbers. The current version of Tcl must be faster than whatever I used when I first did this benchmark (I'm using the same computer). Look in the page history to see the comparison. More importantly, I think I found a bytecoded eval: single-argument try. I added a test for it, and it turns out to be just as fast as the other "fast" methods. It's considerably less weird than if 1, and it doesn't hide errors.

DKF: We've been focusing a bit more on improving the most cripplingly-slow cases, but three execution modes still exist that have fundamentally different speeds. There's compilation to bytecode-with-local-var-table (which is the fastest; the speed comes from being able to compile in indexes into the LVT into the generated bytecode, which this test is particularly sensitive to), there's compilation to bytecode-without-LVT (slower; variables have to be looked up each time they're accessed), and there's interpreting (slowest by far). There's not much point in doing a lot of comparison between the three; they all exist for a reason. (We could make straight eval/uplevel 0 of constant arguments work at full speed, but we see no reason to bother given how rare they are in real code, and it's better that time is kept simple anyway.) You can usually tell what sort of class of speed you're going to get by using [::tcl::unsupported::disassemble] to look at the bytecode to see whether variables are accessed by index or by name, or whether everything's done by just building arguments and invoking “cnormal” commands.

Twylite 2012-08-24: I've been optimising some control constructs and was trying to understand the performance of various combinations of uplevel, tailcall, catch and try. Along the way I found AMG's performance figures, and have updated them with some new ones:

# Fast (prefix f)
proc f_baseline       {} {                 for {set i 0} {$i < 100000} {incr i} {} }
proc f_catch          {} {catch            {for {set i 0} {$i < 100000} {incr i} {}}}
proc f_if_1           {} {if 1             {for {set i 0} {$i < 100000} {incr i} {}}}
proc f_expand         {} {              {*}{for {set i 0} {$i < 100000} {incr i} {}}}
proc f_try            {} {try              {for {set i 0} {$i < 100000} {incr i} {}}}
proc f_time_apply     {} {time {apply {{}  {for {set i 0} {$i < 100000} {incr i} {}}}}}
                     
# Medium (prefix m)             
proc m_eval           {} {eval             {for {set i 0} {$i < 100000} {incr i} {}}}
proc m_uplevel_0      {} {uplevel 0        {for {set i 0} {$i < 100000} {incr i} {}}}
proc m_time           {} {time             {for {set i 0} {$i < 100000} {incr i} {}}}
proc m_tailcall_try   {} {tailcall    try  {for {set i 0} {$i < 100000} {incr i} {}}}
proc m_catch_uplvl_1  {} {       set body  {for {set i 0} {$i < 100000} {incr i} {}} ; catch { uplevel 1 $body } }  
proc m_uplvl_1_catch  {} {       set body  {for {set i 0} {$i < 100000} {incr i} {}} ; uplevel 1 [list catch $body] }  
                     
# Slow (prefix s)               
proc s_eval_list      {} {eval       [list for {set i 0} {$i < 100000} {incr i} {}]}
proc s_uplevel_0_list {} {uplevel 0  [list for {set i 0} {$i < 100000} {incr i} {}]}
proc s_time_list      {} {time       [list for {set i 0} {$i < 100000} {incr i} {}]}
proc s_catch_list     {} {catch      [list for {set i 0} {$i < 100000} {incr i} {}]}
proc s_if_1_list      {} {if 1       [list for {set i 0} {$i < 100000} {incr i} {}]}
proc s_expand_list    {} {        {*}[list for {set i 0} {$i < 100000} {incr i} {}]}
proc s_tailcall       {} {tailcall         for {set i 0} {$i < 100000} {incr i} {} }

if 0 {
    set REPS {f 10 m 40 s 100} ;# reps by prefix
    set cmds {f_baseline f_catch f_if_1 f_expand f_try f_time_apply 
        m_eval m_uplevel_0 m_time m_tailcall_try m_catch_uplvl_1 m_uplvl_1_catch 
        s_eval_list s_uplevel_0_list s_time_list s_catch_list s_if_1_list 
        s_expand_list s_tailcall}

    foreach cmd $cmds {$cmd} ;# compile
    set cmdrepstimes {} ; foreach cmd $cmds { ;# time
        set reps [dict get $::REPS [string index $cmd 0]] 
        lappend cmdrepstimes [lindex [time $cmd $reps] 0] $cmd $reps 
    }
    
    set mintime [::tcl::mathfunc::min {*}$times]
    foreach {t cmd reps} [lsort -real -stride 3 $cmdrepstimes] {
        puts [format "time %-16s $reps\t;# %9.1f microseconds per iteration, factor %5.2f" \
        $cmd $t [expr { $t / $mintime }] ] 
    }
}

time f_time_apply     10        ;#    4625.8 microseconds per iteration, factor  1.00
time f_if_1           10        ;#    4641.8 microseconds per iteration, factor  1.00
time f_expand         10        ;#    4645.0 microseconds per iteration, factor  1.00
time f_catch          10        ;#    4651.3 microseconds per iteration, factor  1.00
time f_baseline       10        ;#    4658.5 microseconds per iteration, factor  1.01
time f_try            10        ;#    4735.9 microseconds per iteration, factor  1.02
time m_eval           40        ;#   18454.3 microseconds per iteration, factor  3.98
time m_uplevel_0      40        ;#   18738.3 microseconds per iteration, factor  4.04
time m_time           40        ;#   19176.8 microseconds per iteration, factor  4.14
time m_uplvl_1_catch  40        ;#   21501.1 microseconds per iteration, factor  4.64
time m_catch_uplvl_1  40        ;#   21603.1 microseconds per iteration, factor  4.66
time m_tailcall_try   40        ;#   21698.4 microseconds per iteration, factor  4.68
time s_uplevel_0_list 100       ;#   84963.3 microseconds per iteration, factor 18.34
time s_eval_list      100       ;#   85519.3 microseconds per iteration, factor 18.46
time s_catch_list     100       ;#   85919.9 microseconds per iteration, factor 18.54
time s_time_list      100       ;#   85944.2 microseconds per iteration, factor 18.55
time s_if_1_list      100       ;#   87269.0 microseconds per iteration, factor 18.84
time s_expand_list    100       ;#   93096.9 microseconds per iteration, factor 20.09
time s_tailcall       100       ;#   94473.5 microseconds per iteration, factor 20.39

Category Command

Tcl syntax help

Arts and crafts of Tcl-Tk programming