Abstracted from Tcl 9.0 WishList in order to keep that page easier to read
Micro Tcl. It should be made easier to separate out features that are unlikely to be needed in embedded systems. Ideally, only a handful commands like set, while, proc, uplevel, upvar, catch, expr and a reduced version of load should be in the interpreter, with everything else linked in as static packages. The reduced load command could then be used to initialize all the other stuff as needed.
LV - I notice that there is a note at http://www.procplace.com/download.html that Karl Lehenbauer mentions they have did a micro tcl, but that it isn't quite ready for prime time - perhaps we can once again borrow from the master (Karl was one of the two primary instigators who created Extended Tcl (TclX) and a number of features from that have made their way into Tcl Prime...
DKF - I looked into this once, and the problem is that a lot of the stuff you need to exclude to reduce the size is in fact the core code which can't be excluded anyway. You need namespaces, stubs, i18n, basic value parsing, variables and the interpreter to operate at all. While you could exclude some of it (top targets are the compiler, RE engine, and date string parser) I'm not sure that these would save you enough. Command load itself is not what you need to tackle, but rather functionality weight...
Volker - Ok, the bigger problem here is to leave out things that are hard to port, like i/o and (as you said) the time/date stuff. Leaving out the compiler would be nice to have but it's not a real show stopper when porting tcl to embedded systems.
Chang - My plan is to get all the commands out of the kernel. Then you could add commands in progressive way. parse, i18n, byte code compiler, stubs are included in the kernel.
Volker - Looks great! Then we could use the parser and set up our very own two or three supported user commands.
Vince - once the new VFS support has been added to the core (TIP 17), it should be very straightforward to remove all filesystem stuff from the micro-kernel.
RWT - I have occasionally pondered the potential benefits of re-architecting the Tcl interpreter using an object oriented decomposition, and writing a new implementation in C++. If, for example, Tcl_Obj's stringRep was implemented as a C++ class, you could have both ASCII and Unicode versions which would be interchangable at compile time (or even run time). I could also imagine using C++'s polymorphism to implement interpreters with and without bytecodes. It seems to me that it might be a good way to modularize the core. I'm just not sure what a good O-O decomposition of a Tcl interpreter would be.
PSE - Well, I can't see why you would even call it Tcl except to invite disaster on Tcl as the teething pains of the C++ reimplementation drives new users away. I'm not sure that programming languages are appropriate targets for object model design. Note that Ruby, which is a beautifully designed OO language, is implemented in C. I would of course chuck all my opinions if confronted by anyone who had actually designed a general purpose language.
JCW - When I coded my TinyTcl [L1 ] in C++ from scratch, I shared RWT's general conviction that C++ would dramatically improve/simplify/modernize such a new scripting core. Nowadays, I avoid C++ ... not because of the language, but because of deployment hassles. It turns out that when coding at such a low level, C++ does not add as much as when it is used in more abstract ways in higher-level tasks. All main scripting languages use C. Perl's "Topaz" was abandoned. Even newcomers such as Lua use C. My current position is that much of a scripting language should be scripted (though evidently not everything). There is no reason why a bytecode compiler has to start out in C, or why Tk's text widget has to be a huge chunk of C (a B-tree, totally tied in, and special purpose, what a waste!). The way to go is to build high-level, and then use machine code sparingly. Preferably as drop-in replacements ("performance plug architecture"). Much easier to code, much easier to test, with optional coding in C or whatever else makes sense. The "Squeak" people got it right [L2 ].
JCW again - Now that CriTcl exists, it has become easier to start modularizing the core. As an example, "xre" in CritLib [L3 ] takes all of the regex/regsub code out and turns it into a loadable extension. Names have been changed to xregex/xregsub. That's over 10,000 lines of C, and about 1/8th of the Tcl binary code. See http://www.equi4.com/critlib/xre.README
See also Small Tcl