Arising from a discussion (on [Tcl chatroom] about the [denotational semantics] of tcl, the concept of ''tcl-null'' was proposed.
[MS] offers this pragmatic approximation of tcl-null:
set cmds [info command]
rename catch _catch
rename rename _rename
foreach c $cmds {_catch {_rename $c {}}}
_rename _catch {}
_rename _rename {}
but notes that [namespace]s also have to be cleaned up. - [RS]: You can have that, and all of the above: a brain-dead interpreter that understands no command any more, with
namespace delete ::
'''tcl-null Game'''
Starting with this as a base, the game is to come up with minimal subset of built-in commands which provide a useful (if not exactly usable) language from which many of the facilities of tcl can be built.
[CMcC] Sat 23rd Sep 2006. One such set is [apply] [set] [uplevel] [list] [lindex] [return]. This resembles the minimal set of lisp functions necessary to construct classic lisp: (eval) (cond) (lambda) (quote) (car) and (cdr) from which McCarthy could construct/emulate classic-lisp. - [RS]: [list] is not needed in the set of fundamentals - the Tcl parser itself builds a list of the arguments before calling a command, so
proc list args {return $args}
The above set constructs [if] as:
proc if {c t f} {uplevel [lindex [list $t $f] [uplevel expr $cond]]}
The construction of [proc] or a near approximation is left as an exercise for the reader. :) [MS] says it can be done. I have no idea how. - [RS] Allowing for an extra [interp] command, [proc] is a special case of [apply]:
proc f x {expr {$x*$x}}
is equivalent to
interp alias {} f {} apply {x {expr {$x*$x}}}
[dgp] pointed out the need for [return] and also adds if your aim is to get back to the full Tcl built-in set, you'll need [trace]
This raises the question of the aim of the tcl-null game. I think there are three possible games:
1. to construct a useful set
2. to construct a usable set
3. to construct the full Tcl built-in set.
----
[[Category Concept]]