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