Lost command.

jima
Published

What happens when we declare an empty command? Let's dive into another silly thought... Imagine that we want a "tracing" mechanism...

proc msg {args} {puts "$args"}

We could have a little helper to report on the local variables like:

proc msgVars {args} {
    set report ""
    foreach v $args {
        upvar 1 $v x
        append report "\n    VAR($v) VALUE($x)"
    }
    append report "\n"
    return $report
}

So a client could order:

proc wea {x y x} {
    # Do stuff... create a var named result...
    msg We had inputs [msgVars x y z] and we produce [msgVars result]
    return $result
}

So far so good. We can happily trace our way while developing our project.

Now, let's mute the trace system in an efficient way. If we do:

proc msg {args} {}

As far as I can say, client script can still refer to msg and the good news is that Tcl does nothing on our behalf in this case... it does literally not waste much processing msg as it is bytecoded out of existence.

But... what happens with arguments to msg...like msgVars. I am afraid those still consume cpu cycles...

Perhaps we could think of a rule that said that if a command is to be a NOP then its arguments could be NOPs too as the general Tcl contract is that arguments are there to be processed by commands.

The fact the substitution performed over the arguments may be plagued by myriad effects seem to be taking precedence though.

At first, one could argue that Tcl is not to decide which things the user might want muted. This point seems good but, to be fair, Tcl does already decide a lot of things on its own in a policy of "sensible default behavior". This could be just another example of following that policy.

A second argument favoring the statu quo is that in reality Tcl does process arguments first by virtue of some highest level decision carved in dodecalogue stone.

See:

[2] Evaluation. A command is evaluated in two steps. First, the Tcl interpreter breaks the command into words and performs substitutions as described below. These substitutions are performed in the same way for all commands. Secondly, the first word is used to locate a command procedure to carry out the command, then all of the words of the command are passed to the command procedure. The command procedure is free to interpret each of its words in any way it likes, such as an integer, variable name, list, or Tcl script. Different commands interpret their words differently.

So, changing this behavior on the nature of the command to be processed ( i.e. don't perform substitution if the command is known to be a NOP) would have really profound implications in the very fabric of Tcl's nature.

After all... in our little example... user still has control and may also do the following:

proc msgVars {args} {}

So the Gods of Tcl may be left placidly sleeping a bit more on their premises undisturbed by users wanting yet another "sensible default" in place.