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