Updated 2012-02-10 02:21:21 by RLE

Aliases are a powerful concept of the interp command, but they lack the direct introspection possibilities that are available for procs. Some interesting of the info subcommands only work on procedures, not on aliases.

Some introspection commands exist, namely the interp subcommands alias, target and aliases. It should however be noted that these operate on alias tokens, which are not necessarily the same as the command-name of the alias, but a unique identifier that was returned when the alias was created. It is usually the same as the command-name specified for the alias, but even that is not guaranteed (a number of colons may have been prepended to that name), and the alias can subsequently have been renamed, so interp alias cannot reliably be used to look up the definition of a command, even if that is known to be an alias.

One can however use an execution trace on an alias command to determine what that command maps to:
 proc which_alias {cmd} {
    uplevel 1 [list ::trace add execution $cmd enterstep ::error]
    catch {uplevel 1 $cmd} res
    uplevel 1 [list ::trace remove execution $cmd enterstep ::error]
    return $res

Below some procs to inspect aliases simliar to info args, a similar proc for info body can be built easily (just use the alias following outlined below and apply info body to the actual target of the alias). Note: Since this procedure was written with the (incorrect) assumption that the interp subcommands will accept any variant of a command name as alias token, it doesn't always work.
    # [info args] like proc following an alias recursivly until it reaches
    # the proc it originates from or cannot determine it. 
    # accounts for default parameters set by interp alias
    proc aliasargs {cmd} {
            set orig $cmd
            set defaultargs [list] 
            # loop until error or return occurs
            while {1} {
                # is it a proc already?
                if {[string equal [info procs $cmd] $cmd]} {
                    set result [info args $cmd] 
                    # strip off the interp set default args
                    return [lrange $result [llength $defaultargs] end]
                # is it a built in or extension command we can get no args for?
                if {![string equal [info commands $cmd] $cmd]} {
                    error "\"$orig\" isn't a procedure"
                # catch bogus cmd names 
                if {[lsearch [interp aliases {}] $cmd]==-1} {
                    error "\"$orig\" isn't a procedure or alias or command" 
                if {[llength [set cmdargs [interp alias {} $cmd]]]>0} {
                    # check if it is aliased in from another interpreter
                    if {[catch {interp target {} $cmd} msg]} {
                        error "Cannot resolve \"$orig\", alias leads to another interpreter."
                    if {$msg != {} } {
                        error "Not recursing into slave interpreter \"$msg\".\
                               \"$orig\" could not be resolved."
                    # check if defaults are set for the alias
                    if {[llength $cmdargs]>1} {
                        set cmd [lindex $cmdargs 0]
                        set defaultargs [concat [lrange $cmdargs 1 end] $defaultargs]
                    } else {
                        set cmd $cmdargs

As it was discussed in the tcl'ers chatroom there are some complex situations that can arise with alias introspection, especially with cross interp aliases.

  • info level, especially with a negative level, may not work as expected
  • uplevel and upvar may do unexpected things

Basically those commands do totally reasonable things, but if a call sequence, this means the list of commands executed, crosses interp boundaries the reasonable may not be the obvious. The main difficulty is the inequality between call sequence and stack level if interp boundaries are crossed. The stack level is an interp local concept, while the call sequence can cross interpreters. The above mentioned commands operate on the stack level, not on the call sequence.