proc eval {command args} { if {[info procs $command] == $command} { foreach [info args $command] $args break eval [info body $command] } elseif {[info commands $command] == $command} { $command $args } }A little rough around the edges, but I never claimed to have fully thought it through ...
Salvatore Sanfilippo: This idea may be used to write a TCL specification that includes just the subset (excluding all the libraries) of TCL that is enough to define all the rest (still excluding libraries). After all TCL is a way to describe a computation using substitutions that can be fully separated from its library and from the higher level abstractions built using it. I wonder if if can be used to write while (hint: it will be more clean to implement some form of escaping continuations so that the TCL core will only include if ;))
Are there not already core Tcl commands that are defined as Tcl procs?AMG: You mean like clock? Sure.
TIP 90 removed the last barrier to being able to create a proc for each built-in Tcl command that behaves exactly like that built-in Tcl command. That is, for every built-in [foo], you can now create a corresponding [myFoo] that is a proc and behaves the same.The proc replacement may need to call the original built-in command, if it exposes functionality not available any other way, for example consider [socket].
RS 2006-08-28: Some built-ins can equivalently be implemented in pure-Tcl (showing a slight redundancy):
interp alias {} eval {} uplevel 0 proc list args {set args}
CMcC 2007-01-13: One of the virtues of Tcl in Tcl is that it serves as templates for creation of little languages in pure Tcl.For example, an aspect of expect is a switch-like language. The pattern is [action]:match->[consequence] ..., which is reminiscent of Edsger Dijkstra's guarded if, as is switch.I mention this because I'm writing something akin to pattern-matching.