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 [set]s 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?

----
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]].
----
[category internals]