The discussion of If we had no if got me thinking - what core commands can be written in terms of other core commands, and which are just syntactic sugar or optimizations? Maybe if we could hook into eval to redo tcl's read-eval-print loop then things like proc become a simple lookup into a hashtable, a few sets and another eval..
Maybe something like
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.