The [Dodekalogue] which defines Tcl is completely recursive, in that command substitution is performed over words (7. Command Substitution) and over the completely-substituted command (2. Evaluation).

It is useful to consider incompletely recursive Tcl, where the invariant in (2. Evaluation, 'These substitutions are performed in the same way for all commands') was abrogated.

One reason to consider this is that the universality of application seems to be surplus to requirements... it seems that it restates in (2.) what is already strongly implied by (7.) through (2.)  As [post-Euclidean Tcl] suggests, there may be virtue in reconsidering this kind of duplication and over-constraint.

It is worth noting that Tcl (as defined by the Dodekalogue) is only defined with respect to command substitution where those commands are reachable from the namespace.  The [unknown] functionality is not specified by the Dodekalogue, which is silent on what occurs if a command name does not resolve to a command.  As [unknown] is given the fully-substituted list which was to be evaluated, it is freely able to re-interpret the list however it chooses.  This permits some non-Tcl languages to be implemented over Tcl.

Another reason abrogating the universal-application sub-rule makes sense is that it permits one to do interesting things within Tcl's incompletely recursive definition, which supports the simulation of almost-Tcl within Tcl.

Consider one example of such a useful almost-Tcl language, modeled on .ini file format:
=====
    section {
        var value
        var1 value1; var2 value2
    }

    section2 {
        # this defines section2
        var value; var1 [expr {$var * 2 + $section::var1}]
    }
=====

As a means of initializing a dict, or series of namespaces where one is only interested in assigning values to 'variable' names within sections within that structure.

Currently, Tcl does not directly support this kind of language using [unknown], as it is impossible to distinguish between a substitution under Dodekalogue (2. STEP 1) word substition and (2. STEP 2) command substitution, and thus impossible to apply different command semantics according to the command's role. 

<<categories>>Enter Category Here