Updated 2015-04-10 20:48:43 by dbohdan

DKF: What is the very minimum set of Tcl commands? Here's an attempt to define them:
string
You have to have some tools to manipulate strings, match them, etc. Could probably leave some parts of this command out. However, strings must use UTF-8 or UNICODE.
expr
You must be able to evaluate expressions.
catch
You must be able to trap errors.
"loop"
While you can use expr to construct if, looping is the only way to get to Turing-completeness (assuming we don't have a very deep stack, as is usually the case!) This could be a simple infinite loop though, with break to terminate it.
return
Speaking of which, we do not need break (or continue or error) if we have this command.
proc
It's not Tcl if you can't create your own commands!
uplevel
This is critical to being able to make your own control constructs, and it is a clear defining feature of how Tcl really works. Also subsumes eval.
rename
All Tcl commands are renameable, and that's vital to how much of the language works internally.
set
Need to be able to set variables.
unset
Need to be able to remove variables.
upvar
This subsumes global and variable, and is also tremendously useful for control constructs again.
"basic IO"
The aim with this is to build enough to support source, though that command is so simple to reimplement in Tcl that it can't be fundamental. However, a minimal command set need not support writing files. If you insist on keeping the workload down, just do source for this.
info
Introspection is a key feature of Tcl, but quite a bit of this command (like string, as mentioned above) can be omitted.
unknown
Technically, you don't need to have this. But you do need to have plumbed in support for it; it's the final key defining factor of the language.

Things to go in the second orbit:
interp
This is the heart of our security model.
namespace
There is no other way to do much of this command either.
trace
Another fundamental piece that can be omitted from a minimum minimal system.

Note that there are no list commands; they are reimplementable in terms of string manipulation (though that'll be slow, of course). I've omitted REs too (big, but not fundamental) and dicts (nice to have, but again not required). Also, the fully-featured subst is hard to do in any other way, but it's not used that much and can be omitted while still allowing most scripts to run just fine.

Discussion edit

CL: Donal launched this page while philosophizing for the benefit of the Parroteers. I find namespace dispensable, and agrees that REs and dicts are as well. Donal commented, "Note that I'd put encodings and the fuller channel/event model further out. They're vital, but not the heart of the story." I think they are fundamental, in a specific sense, but I'll let them pass for now.

DKF: The channel and event layer (including the encoding command) is actually fairly separable from the rest of Tcl. If someone's going to reimplement Tcl, I'd suggest they start elsewhere.

Lars H: I think it needs to be pointed out that what is being minimized here is the number of core commands. This measure will tend to favorize huge ensembles like string and little languages like expr over alternative primitives that might be more natural or easier to implement, so I'm a bit skeptical about the above list being an optimal "minimal Tcl". Besides, what about format and scan? Languages that can't do string<->numeric conversions (both as value and as character code) tend to be too limited for many purposes.

DKF: I was actually thinking in terms of things that it would be really hard to implement any other way, so string gives you the basic things you need for pulling strings apart (it is string compare, string index and string range that are critical) and working out what is in them, which in turn allows you to build the list and dict operations. Getting up to the level of handling format and scan requires a bit more (you need expressions and loops so you can build the code to parse the format strings) but neither is fundamental.

Also, with expr it would be reasonable to leave out (at least initially) the floating point handling (including all functions). While yes, you do want it, it is far more optional than the integer math parts which are vital for building other commands.

See also edit