 | |
 | |
 | ||||||
contents
| 6 - One intriguing possibility ... Critcl need not be limited just to Tcl applications and extensions. One idea is to experiment with the concept of "systems scripting". Just as a generation ago systems programming moved from assembler to C, the time may be right to shift to a predominantly scripted model. The Squeak language [17] has been implemented this way, using C as "assembly" but coding even its own Virtual Machine as Squeak/Smalltalk code which then generates C. And Squeak is no performance slouch - partly because low-level designs can be radically altered with little effort (which the authors did when switching to Forth's Threaded Code model). Using this approach for Tcl, the first step would be to generate tcl.h (and the other header files) from the stub table definitions themselves, and to generate stub entries (i.e. not just the C functions) for binding to Tcl using the Tcl_CreateObjCommand. This would make it possible to gradually replace parts of Tcl itself with CriTcl-built code. Taking this last idea further - the Tcl API could be split into "primary" and "secondary" calls, and Critcl used to build the secondary ones. This would be a first step towards modularisation, and a smaller Tcl core. One could for example take the regex subsystem, turn it into a Critcl module and make it optional - or at least allow a developer to switch between minimal and full-scale versions (the "xre" example in CritLib shows that regex can indeed be built separately). More practical, perhaps, would be to use this approach to turn the native file system interface into a module. Other candidates might be the bytecode compiler, the channel subsystem, or the exec/pipe-open/load interfaces. Taken to extremes, the "tcl.h" plus "tcl.decls" headers could become the center of Tcl, with everything else plugged in - leading to an equivalent but deeply modular core, and a workbench for future yet more radical Tcl changes. It will indeed take some pretty capable coders to implement this approach, but only at the "bottom end". Once the mechanism is in place and a foundation working, everything else can be written in Tcl (albeit a limited subset) by people who know little about C. Then, at some point a Tcl+C expert can go through what has been implemented, pick a hot spot, and replace Tcl by a Tcl/C mix using Critcl. Maybe Tcl is not the optimal language for this approach but, on the other hand, maybe it is so malleable that it might just work. Even the OS and compilers themselves would be candidates for this approach - end up with more general and flexible "skeletons" on which everything else rests. A first step in this direction has been taken recently by Andreas Kupries - the Scripted Compiler project [18]. Using this, one could write a "C to machine code" translator in Tcl and end up with a system which can generate and maintain itself with no compiler at all (except for the usual bootstrap issues). The trend and motivation in all of the above is not to redo things just for the fun of it, but to attempt to change the core/systems development from a compiled to a scripting model and in doing so, realise the same benefits of productivity, flexibility and extensibility. | see also | ||||
| | | | | | |
| | |