TinyMUSH now embeds Tcl (the Tool Command Language) as the recommended extension language for projects beyond the scope of normal TinyMUSH code. The inclusion of an embedded programming language came about for a variety of reasons. People were increasingly embarking upon code projects that involved server modifications; this, I feel, is fundamentally the wrong approach, particularly as it makes it difficult to upgrade between official releases of the server. I felt that it would be beneficial to provide a more traditionally-structured programming language, with access to common MUSH primitives, for those interested in writing extremely complex systems. Originally, my language of choice for this was GNU's Guile, a dialect of Scheme, which is in turn a dialect of LISP, and thus conceptually similar to the functional-programming-oriented existing MUSH language. Unfortunately, the Guile API proved to be in a state of flux, with no convenient way to restrict access to privileged system functions. Jellan of PernMUSH suggested Tcl instead, and this proved to be a very agreeable language to work with. I also looked at the possibility of perl or python, but discarded both ideas in short order. Tcl has a number of solid advantages. First, it is a very popular embedded scripting language, which means that many people are already familiar with it -- and for those who don't know it, it's a programming skill useful in the Real World; its syntax is also C-like, traditionally procedural, and thus easier for many people to wrap their brains around. Second, it is stable, well-supported, has a clearly-documented and easy-to-use API, and has a large body of "How to Learn Tcl" literature, both on-line and off-line. Third, it has a "safe mode", which automatically excludes file operations and other things that need to be disabled for security reasons. Fourth, it's possible to write a Tcl library to simulate a MUSH environment, thus letting people test Tcl scripts off-MUSH. In the future, depending on how this experiment works out, it may be worthwhile to make it easy to modify the server to add Tcl extensions; this should serve the needs of many programmers who want to add extensions in C for speed, but who want to avoid a lot of customer server hacking. A cautionary note is needed here, though. The Tcl interpreter does NOT timeslice, and as a result, it is possible for a Tcl program to hang the MUSH in an infinite loop. If this happens to you, try sending a SIGUSR1 to the process (which should perform the equivalent of a @restart); if that doesn't work, you'll need to kill and restart the MUSH. I consider this a "reasonable risk"; it's no worse than one could do with a server modification, and indeed, generally less risky than server modifications. It is not intended for casual use; the decision to write a piece of code in Tcl rather than in straight MUSHcode should not be taken lightly, and as such, the TICKLER flag, which controls whether or not an object can use these functions, can only be set by God. It should also be noted that there is one instance of the interpreter spawned for every object calling the TclEval() function. For memory usage efficiency, the number of objects executing Tcl should be kept as small as possible, since a separate interpreter thread is required for each such object. The base memory overhead for an interpreter instance is small, but it can grow as variables are stored, and so forth. The interpreter is persistent unless explicitly destroyed, and thus whenever one begins executing a Tcl script, one had best make sure that the state of the interpreter is what one thinks it is; semaphore-timed resets of the interpreter may be the most advisable thing when concurrency is an issue. The Tcl module has been tested with Tcl 7.6. Results with other versions may be unpredictable. This functionality should still be considered strictly experimental. -- Amberyl June 29th, 1997