Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/misc/volume25/tcl/part31

Text File | 1991-11-15 | 43.3 KB | 826 lines

Newsgroups: comp.sources.misc
From: [e-mail] (Karl Lehenbauer)
Subject:  v25i099:  tcl - tool command language, version 6.1, Part31/33
Message-ID: <[e-mail]>
X-Md4-Signature: 18b6bb80ea9b129780668efa8b4edd19
Date: Fri, 15 Nov 1991 23:01:00 GMT
Approved: [e-mail]

Submitted-by: [e-mail] (Karl Lehenbauer)
Posting-number: Volume 25, Issue 99
Archive-name: tcl/part31
Environment: UNIX

#! /bin/sh
# This is a shell archive.  Remove anything before this line, then unpack
# it by saving it into a file and typing "sh file".  To overwrite existing
# files, type "sh file -c".  You can also feed this as standard input via
# unshar, or by typing "sh <file", e.g..  If this archive is complete, you
# will see the following message at the end:
#        "End of archive 31 (of 33)."
# Contents:  tcl6.1/doc/usenix.text
# Wrapped by karl@one on Tue Nov 12 19:44:33 1991
PATH=/bin:/usr/bin:/usr/ucb ; export PATH
if test -f 'tcl6.1/doc/usenix.text' -a "${1}" != "-c" ; then
  echo shar: Will not clobber existing file \"'tcl6.1/doc/usenix.text'\"
else
echo shar: Extracting \"'tcl6.1/doc/usenix.text'\" \(41391 characters\)
sed "s/^X//" >'tcl6.1/doc/usenix.text' <<'END_OF_FILE'
XTcl: An Embeddable Command Language
XJohn K. Ousterhout
XComputer Science Division
XElectrical Engineering and Computer Sciences
XUniversity of California at Berkeley
XBerkeley, CA 94720
[e-mail]
X
XABSTRACT
X
XTcl is an interpreter for a tool command language.  It consists of a library
Xpackage that is embedded in tools (such as editors, debuggers, etc.) as the
Xbasic command interpreter.  Tcl provides (a) a parser for a simple textual
Xcommand language, (b) a collection of built-in utility commands, and (c)
Xa C interface that tools use to augment the built-in commands with
Xtool-specific commands.  Tcl is particularly attractive when integrated with
Xthe widget library of a window system: it increases the programmability of
Xthe widgets by providing mechanisms for variables, procedures, expressions,
Xetc; it allows users to program both the appearance and the actions of
Xwidgets; and it offers a simple but powerful communication mechanism between
Xinteractive programs.
X
XThe work described here was supported in part by the National Science
XFoundation under Grant ECS-8351961.
X
X
X1.  Introduction
X
XTcl stands for ``tool command language''.  It consists of a library package
Xthat programs can use as the basis for their command languages.  The
Xdevelopment of Tcl was motivated by two observations.  The first observation
Xis that a general-purpose programmable command language amplifies the power
Xof a tool by allowing users to write programs in the command language in
Xorder to extend the tool's built-in facilities.  Among the best-known
Xexamples of powerful command languages are those of the UNIX shells [5]
Xand the Emacs editor [8].  In each case a computing environment of unusual
Xpower has arisen, in large part because of the availability of a pro-
Xgrammable command language.
X
XThe second motivating observation is that the number of interactive
Xapplications is increasing.  In the timesharing environments of the late
X1970's and early 1980's almost all programs were batch-oriented.  They
Xwere typically invoked using an interactive command shell.  Besides the
Xshell, only a few other programs needed to be interactive, such as editors
Xand mailers.  In contrast, the personal workstations used today, with their
Xraster displays and mice, encourage a different system structure where a
Xlarge number of programs are interactive and the most common style of
Xinteraction is to manipulate individual applications directly with a mouse.
XFurthermore, the large displays available today make it possible for many
Xinteractive applications to be active at once, whereas this was not practical
Xwith the smaller screens of ten years ago.
X
XUnfortunately, few of today's interactive applications have the power of the
Xshell or Emacs command languages.  Where good command languages exist, they
Xtend to be tied to specific programs.  Each new interactive application
Xrequires a new command language to be developed.  In most cases application
Xprogrammers do not have the time or inclination to implement a general-purpose
Xfacility (particularly if the application itself is simple), so the resulting
Xcommand languages tend to have insufficient power and clumsy syntax.
X
XTcl is an application-independent command language.  It exists as a
XC library package that can be used in many different programs.  The
XTcl library provides a parser for a simple but fully programmable command
Xlanguage.  The library also implements a collection of built-in commands
Xthat provide general-purpose programming constructs such as variables,
Xlists, expressions, conditionals, looping, and procedures.  Individual
Xapplication programs extend the basic Tcl language with application-specific
Xcommands.  The Tcl library also provides a set of utility routines to simplify
Xthe implementation of tool-specific commands.
X
XI believe that Tcl is particularly useful in a windowing environment, and that
Xit provides two advantages.  First, it can be used as a general-purpose
Xmechanism for programming the interfaces of applications.  If a tool is based
Xon Tcl, then it should be relatively easy to modify the application's user
Xinterface and to extend the interface with new commands.  Second, and more
Ximportant, Tcl provides a uniform framework for communication between tools.
XIf used uniformly in all tools, Tcl will make it possible for tools to work
Xtogether more gracefully than is possible today.
X
XThe rest of this paper is organized as follows.  Section 2 describes the
XTcl language as seen by users.  Section 3 discusses how Tcl is used in
Xapplications, including the C-language interface between application
Xprograms and the Tcl library.  Section 4 describes how Tcl can be used
Xin a windowing environment to customize interface actions and appearances.
XSection 5 shows how Tcl can be used as a vehicle for communication between
Xapplications, and why this is important.  Section 6 presents the status
Xof the Tcl implementation and some preliminary performance measurements.
XSection 7 compares Tcl to Lisp, Emacs, and NeWS, and Section 8 concludes
Xthe paper.
X
X2.  The Tcl Language
X
XIn a sense, the syntax of the Tcl language is unimportant: any programming
Xlanguage, whether it is C [6], Forth [4], Lisp [1], or Postscript [2],
Xcould provide many of the same programmability and communication advantages
Xas Tcl.  This suggests that the best implementation approach is to borrow
Xan existing language and concentrate on providing a convenient framework for
Xthe use of that language.  However, the environment for an embeddable command
Xlanguage presents an unusual set of constraints on the language, which are
Xdescribed below.  I eventually decided that a new language designed from
Xscratch could probably meet the constraints with less implementation effort
Xthan any existing language.
X
XTcl is unusual because it presents two different interfaces: a textual
Xinterface to users who issue Tcl commands, and a procedural interface to the
Xapplications in which it is embedded.  Each of these interfaces must be
Xsimple, powerful, and efficient.  There were four major factors in the
Xlanguage design:
X
X[1] The language is for commands.
X
XAlmost all Tcl ``programs'' will be short, many only one line long.  Most
Xprograms will be typed in, executed once or perhaps a few times, and then
Xdiscarded.  This suggests that the language should have a simple syntax so
Xthat it is easy to type commands.  Most existing programming languages have
Xcomplex syntax; the syntax is helpful when writing long programs but would
Xbe clumsy if used for a command language.
X
X[2] The language must be programmable.
X
XIt should contain general programming constructs such as variables,
Xprocedures, conditionals, and loops, so that users can extend the built-in
Xcommand set by writing Tcl procedures.  Extensibility also argues for
Xa simple syntax: this makes it easier for Tcl programs to generate other
XTcl programs.
X
X[3] The language must permit a simple and efficient interpreter.
X
XFor the Tcl library to be included in many small programs, particularly
Xon machines without shared-library facilities, the interpreter must not
Xoccupy much memory.  The mechanism for interpreting Tcl commands must be
Xfast enough to be usable for events that occur hundreds of times a second,
Xsuch as mouse motion.
X
X[4] The language must permit a simple interface to C applications.
X
XIt must be easy for C applications to invoke the interpreter and easy
Xfor them to extend the built-in commands with application-specific
Xcommands.  This factor was one of the reasons why I decided not to
Xuse Lisp as the command language: Lisp's basic data types and storage
Xmanagement mechanisms are so different than those of C that it would
Xbe difficult to build a clean and simple interface between them.
X
XFor Tcl I used a data type (string) that is natural to C.
X
X2.1.  Tcl Language Syntax
X
XTcl's basic syntax is similar to that of the UNIX shells: a command consists
Xof one or more fields separated spaces or tabs.  The first field is the name
Xof a command, which may be either a built-in command, an application-specific
Xcommand, or a procedure consisting of a sequence of Tcl commands.  Fields
Xafter the first one are passed to the command as arguments.  Newline
Xcharacters are used as command separators, just as in the UNIX shells, and
Xsemi-colons may be used to separate commands on the same line.  Unlike the
XUNIX shells, each Tcl command returns a string result, or the empty string
Xif a return value isn't appropriate.
X
XThere are four additional syntactic constructs in Tcl, which give the language
Xa Lisp-like flavor.  Curly braces are used to group complex arguments; they
Xact as nestable quote characters.  If the first character of an argument is a
Xopen brace, then the argument is not terminated by white space.  Instead, it
Xis terminated by the matching close brace.  The argument passed to the command
Xconsists of everything between the braces, with the enclosing braces stripped
Xoff.  For example, the command
X
X    set a {dog cat {horse cow mule} bear}
X
Xwill receive two arguments: ``a'' and ``dog cat {horse cow mule} bear''.
XThis particular command will set the variable
X    a
Xto a string equal to the second argument.  If an argument is enclosed
Xin braces, then none of the other substitutions described below is made
Xon the argument.  One of the most common uses of braces is to specify a
XTcl subprogram as an argument to a Tcl command.
X
XThe second syntactic construct in Tcl is square brackets, which are used to
Xinvoke command substitution.  If an open bracket appears in an argument, then
Xeverything from the open bracket up to the matching close bracket is treated
Xas a command and executed recursively by the Tcl interpreter.  The result of
Xthe command is then substituted into the argument in place of the bracketed
Xstring.  For example, consider the command
X
X    set a [format {Santa Claus is %s years old} 99]
X
XThe format command does printf-like formatting and returns the string
X``Santa Claus is 99 years old'', which is then passed to set and assigned
Xto variable a.
X
XThe third syntactic construct is the dollar sign, which is used for variable
Xsubstitution.  If it appears in an argument then the following characters are
Xtreated as a variable name; the contents of the variable are substituted into
Xthe argument in place of the dollar sign and name.  For example, the commands
X
Xset b 99
Xset a [format {Santa Claus is %s years old} $b]
X
Xresult in the same final value for a as the single command in the previous
Xparagraph.  Variable substitution isn't strictly necessary since there are
Xother ways to achieve the same effect, but it reduces typing.
X
XThe last syntactic construct is the backslash character, which may be used
Xto insert special characters into arguments, such as curly braces or
Xnon-printing characters.
X
X2.2.  Data Types
X
XThere is only one type of data in Tcl: strings.  All commands, arguments
Xto commands, results returned by commands, and variable values are ASCII
Xstrings.  The use of strings throughout Tcl makes it easy to pass information
Xback and forth between Tcl library procedures and C code in the enclosing
Xapplication.  It also makes it easier to pass Tcl-related information back
Xand forth between machines of different types.
X
XAlthough everything in Tcl is a string, many commands expect their string
Xarguments to have particular formats.  There are three particularly common
Xformats for strings: lists, expressions, and commands.  A list is just a
Xstring containing one or more fields separated by white space, similar to
Xa command.  Curly braces may be used to enclose complex list elements; these
Xcomplex list elements are often lists in their own right, as in Lisp.  For
Xexample, the string
X
X    dog cat {horse cow mule} bear
X
Xis a list with four elements, the third of which is a list with three
Xelements.  Tcl provides commands for a number of list-manipulation operations,
Xsuch as creating lists, extracting elements, and computing list lengths.
X
XThe second common form for a string is a numeric expression.  Tcl
Xexpressions have the same operators and precedence as expressions in C.
XThe "expr" Tcl command evaluates a string as an expression and returns the
Xresult (as a string, of course).  For example, the command
X
Xexpr {($a < $b) || ($c != 0)}
X
Xreturns ``0'' if the numeric value of variable a is less than that of
Xvariable b, or if variable c is not zero; otherwise it returns
X``0''.  Several other commands, such as "if" and "for", expect one or more
Xof their arguments to be expressions.
X
XThe third common interpretation of strings is as commands (or sequences of
Xcommands).  Arguments of this form are used in Tcl commands that implement
Xcontrol structures.  For example, consider the following command:
X
Xif {$a < $b} {
X    set tmp $a
X    set a $b
X    set b $tmp
X}
X
XThe "if" command receives two arguments here, each of which is delimited
Xby curly braces.  "If" is a built-in command that evaluates its first
Xargument as an expression; if the result is non-zero, "if" executes its
Xsecond argument as a Tcl command.  This particular command swaps the
Xvalues of the variables "a" and "b" if "a" is less than "b".
X
XTcl also allows users to define command procedures written in the Tcl
Xlanguage.  I will refer to these procedures as tclproc's, in order to
Xdistinguish them from other procedures written in C.  The "proc" built-in
Xcommand is used to create a tclproc.  For example, here is a Tcl command
Xthat defines a recursive factorial procedure:
X
Xproc fac x {
X    if {$x == 1} {return 1}
X    return [expr {$x * [fac [expr $x-1]]}]
X}
X
XThe "proc" command takes three arguments: a name for the new tclproc, a
Xlist of variable names (in this case the list has only a single element,
X"x"), and a Tcl command that comprises the body of the tclproc.  Once
Xthis proc command has been executed, "fac" may be invoked just like any
Xother Tcl command.  For example
X
X    fac 4
X
Xwill return the string ``24''.
X
XFigure 1 lists all of the built-in Tcl commands in groups.  In addition to
Xthe commands already mentioned, Tcl provides commands for manipulating
Xstrings (comparison, matching, and printf/scanf-like operations), commands
Xfor manipulating files and file names, and a command to fork a subprocess
Xand return the subprocess's standard output as result.  The built-in Tcl
Xcommands provide a simple but complete programming language.  The built-in
Xfacilities may be extended in three ways: by writing tclprocs; by invoking
Xother programs as subprocesses; or by defining new commands with C
Xprocedures as described in the next section.
X
X3.  Embedding Tcl in Applications
X
XAlthough the built-in Tcl commands could conceivably be used as a
Xstand-alone programming system, Tcl is really intended to be embedded
Xin application programs.  I have built several application programs using
XTcl, one of which is a mouse-based editor for X called "mx".  In the rest
Xof the paper I will use examples from mx to illustrate how Tcl interacts
Xwith its enclosing application.
X
XAn application using Tcl extends the built-in commands with a few
Xadditional commands related to that particular application.  For
Xexample, a clock program might provide additional commands to control
Xhow the clock is displayed and to set alarms; the mx editor provides
Xadditional commands to read a file from disk, display it in a window,
Xselect and modify ranges of bytes, and write the modified file back to
Xdisk.  An application programmer need only write the application-specific
Xcommands; the built-in commands provide programmability and extensibility
X``for free''.  To users, the application-specific commands appear the same
Xas the built-in commands.
X
XFigure 2 shows the relationship between Tcl and the rest of an application.
XTcl is a C library package that is linked with the application.  The Tcl
Xlibrary includes a parser for the Tcl language, procedures to execute the
Xbuilt-in commands, and a set of utility procedures for things like expression
Xevaluation and list management.  The parser includes an extension interface
Xthat may be used to extend the language's command set.
X
XTo use Tcl, an application first creates an object called an "interpreter",
Xusing the following library procedure:
X
X    Tcl_Interp *Tcl_CreateInterp()
X
XAn interpreter consists of a set of commands, a set of variable bindings,
Xand a command execution state.  It is the basic unit manipulated by most
Xof the Tcl library procedures.
X
XSimple applications will use only a single interpreter, while more complex
Xapplications may use multiple interpreters for different purposes.  For
Xexample, mx uses one interpreter for each window on the screen.
X
XThe Tcl library provides a parser for the Tcl language, a set of built-in
Xcommands, and several utility procedures.  The application provides
Xapplication-specific commands plus procedures to collect commands for
Xexecution.  The commands are parsed by Tcl and then passed to relevant
Xcommand procedures (either in Tcl or in the application) for execution.
X
XOnce an application has created an interpreter, it calls the
XTcl_CreateCommand procedure to extend the interpreter with
Xapplication-specific commands:
X
Xtypedef int Tcl_CmdProc((ClientData) clientData, Tcl_Interp *interp,
X    int argc, char *argv[]);
X
XTcl_CreateCommand(Tcl_Interp *interp, char *name, Tcl_CmdProc proc,
X    ClientData clientData)
X
XEach call to Tcl_CreateCommand associates a particular command name
X(name) with a procedure that implements that command (proc) and an
Xarbitrary single-word value to pass to that procedure (clientData).
X
XAfter creating application-specific commands, the application enters
Xa main loop that collects commands and passes them to the Tcl_Eval
Xprocedure for execution:
X
X    int Tcl_Eval(Tcl_Interp *interp, char *cmd)
X
XIn the simplest form, an application might simply read commands from the
Xterminal or from a file.  In the mx editor Tcl commands are associated
Xwith events such as keystrokes, mouse buttons, or menu activations; each
Xtime an event occurs, the corresponding Tcl command is passed to Tcl_Eval.
X
XThe Tcl_Eval procedure parses its cmd argument into fields, looks up the
Xcommand name in the table of those associated with the interpreter, and
Xinvokes the command procedure associated with that command.  All command
Xprocedures, whether built-in or application-specific, are called in the
Xsame way, as described in the typedef for Tcl_CmdProc above.
XA command procedure is passed an array of strings describing the command's
Xarguments (argc and argv) plus the clientData value that was associated
Xwith the command when it was created.  ClientData is typically a pointer
Xto an application-specific structure containing information needed to
Xexecute the command.  For example, in mx the clientData argument points
Xto a per-window data structure describing the file being edited and the
Xwindow it is displayed in.
X
XControl mechanisms like "if" and "for" are implemented with recursive
Xcalls to Tcl_Eval.  For example, the command procedure for the "if"
Xcommand evaluates its first argument as an expression; if the result
Xis non-zero, then it calls Tcl_Eval recursively to execute its second
Xargument as a Tcl command.  During the execution of that command, Tcl_Eval
Xmay be called recursively again, and so on.  Tcl_Eval also calls itself
Xrecursively to execute bracketed commands that appear in arguments.
X
X
XEven tclprocs such as fac use this same basic mechanism.
XWhen the "proc" command is invoked to create "fac", the proc command
Xprocedure creates a new command by calling Tcl_CreateCommand as
Xillustrated in Figure 3.  The new command has the name "fac".  Its
Xcommand procedure ("proc" in the call to Tcl_CreateCommand) is a
Xspecial Tcl library procedure called "InterpProc", and its clientData
Xis a pointer to a structure describing the tclproc.  This structure
Xcontains, among other things, a copy of the body of the tclproc (the
Xthird argument to the proc command).  When the fac command is invoked,
XTcl_Eval calls InterpProc, which in turn calls Tcl_Eval to execute the
Xbody of the tclproc.  There is some additional code required to associate
Xthe argument of the fac command (which is passed to InterpProc in its argv
Xarray) with the "x" variable used inside fac's body, and to support variables
Xwith local scope, but much of the mechanism for tclprocs is the same as that
Xfor any other Tcl command.
X
XThe creation and execution of a tclproc (a procedure written in Tcl):
X(a) the proc command is invoked, e.g.  to create the fac procedure; (b)
Xthe Tcl parser invokes the command procedure associated with proc; (c)
Xthe proc command procedure creates a data structure to hold the Tcl
Xcommand that is fac's body; (d) fac is registered as a new Tcl command,
Xwith InterpProc as its command procedure; (e) fac is invoked as a Tcl
Xcommand; (f) the Tcl parser invokes InterpProc as the command procedure
Xfor fac; (g) InterpProc retrieves the body of fac from the data structure;
Xand (h) the Tcl commands in fac's body are passed back to the Tcl parser
Xfor execution.
X
XA Tcl command procedure returns two results to Tcl_Eval: an integer return
Xcode and a string.  The return code is returned as the procedure's result,
Xand the string is stored in the interpreter, from which it can be retrieved
Xlater.  Tcl_Eval returns the same code and string to its caller.
X
XTable I summarizes the return codes and strings.
X
XNormally the return code is TCL_OK and the string contains the result of
Xthe command.  If an error occurs in executing a command, then the return
Xcode will be TCL_ERROR and the string will describe the error condition.
XWhen TCL_ERROR is returned (or any value other than TCL_OK), the normal
Xaction is for nested command procedures to return the same code and string
Xto their callers, unwinding all pending command executions until eventually
Xthe return code and string are returned by the top-level call to Tcl_Eval.
XAt this point the application will normally display the error message for
Xthe user by printing it on the terminal or displaying it in a notifier
Xwindow.
X
XReturn codes other than TCL_OK or TCL_ERROR cause partial unwinding.  For
Xexample, the break command returns a TCL_BREAK code.  This causes nested
Xcommand executions to be unwound until a nested "for" or "foreach" command
Xis reached.  When a "for" or "foreach" command invokes Tcl_Eval recursively,
Xit checks specially for the TCL_BREAK result.  When this occurs the "for" or
X"foreach" command terminates the loop, but it doesn't return the TCL_BREAK
Xcode to its caller.  Instead it returns TCL_OK.  Thus no higher levels of
Xexecution are aborted.  The TCL_CONTINUE return code is also handled by the
X"for" and "foreach" commands (they go on to the next loop iteration) and
XTCL_RETURN is handled by the InterpProc procedure.  Only a few command
Xprocedures, like "break" and "for", know anything about special return codes
Xsuch as TCL_BREAK; other command procedures simply abort whenever they see any
Xreturn code other than TCL_OK.
X
XThe "catch" command may be used to prevent complete unwinding on TCL_ERROR
Xreturns.  Catch takes an argument that is a Tcl command to execute.  It
Xpasses the command to Tcl_Eval for execution, but always returns TCL_OK.
XIf an error occurs in the command, catch's command procedure detects the
XTCL_ERROR return value from Tcl_Eval, saves information about the error
Xin Tcl variables, and then returns TCL_OK to its caller.  In almost all
Xcases I think the best response to an error is to abort all command
Xinvocations and notify the user; catch is provided for those few occasions
Xwhere an error is expected and can be handled without aborting.
X
X4.  Tcl and Window Applications
X
XAn embeddable command language like Tcl offers particular advantages in
Xa windowing environment.  This is partly because there are many interactive
Xprograms in a windowing environment (hence many places to use a command
Xlanguage) and partly because configurability is important in today's
Xwindowing environments and a language like Tcl provides the flexibility
Xto reconfigure.
X
XTcl can be used for two purposes in a window application: to configure the
Xapplication's interface actions, and to configure the application's
Xinterface appearance.  These two purposes are discussed in the paragraphs
Xbelow.
X
XThe first use of Tcl is for interface actions.  Ideally, each event that
Xhas any importance to the application should be bound to a Tcl command.
XEach keystroke, each mouse motion or mouse button press (or release), and
Xeach menu entry should be associated with a Tcl command.  When the event
Xoccurs, it is first mapped to its Tcl command and then executed by passing
Xthe command to Tcl_Eval.  The application should not take any actions
Xdirectly; all actions should first pass through Tcl.  Furthermore, the
Xapplication should provide Tcl commands that allow the user to change the
XTcl command associated with any event.
X
XIn interactive windowing applications, the use of Tcl will probably not be
Xvisible to beginning users: they will manipulate the applications using
Xbuttons, menus, and other interface components.  However, if Tcl is used as
Xan intermediary for all interface actions then two advantages accrue.  First,
Xit becomes possible to write Tcl programs to reconfigure the interface.
XFor example, users will be able to rebind keystrokes, change mouse buttons,
Xor replace an existing operation with a more complex one specified as a set of
XTcl commands or tclprocs.  The second advantage is that this approach forces
Xall of the application's functionality to be accessible through Tcl: anything
Xthat can be invoked with the mouse or keyboard can also be invoked with Tcl
Xprograms.  This makes it possible to write tclprocs that simulate the actions
Xof the program, or that compose the program's basic actions into more powerful
Xactions.  It also permits interactive sessions to be recorded and replayed as
Xa sequence of Tcl commands (see Section 5).
X
XThe second use for Tcl in a window application is to configure the appearance
Xof the application.  All of the application's interface components
X(``widgets'' in X terminology), such as labels, buttons, text entries, menus,
Xand scrollbars, should be configured using Tcl commands.  For example, in
Xthe case of a button the application (or the button widget code) should provide
XTcl commands to change the button's size and location, its text, its colors,
Xand the action (a Tcl command, of course) to invoke when the button is
Xactivated.  This makes it possible for users to write Tcl programs to
Xpersonalize the layout and appearance of the applications they use.  The most
Xcommon use of such reconfigurability would probably be in Tcl command files
Xread by programs automatically when they start execution.  However, the
XTcl commands could also be used to change an application's appearance while
Xit is running, if that should prove useful.
X
XIf Tcl is used as described above, then it could serve as a specification
Xlanguage for user interfaces.  User interface editors could be written to
Xdisplay widgets and let users re-arrange them and configure attributes such
Xas colors and associated Tcl commands.  The interface editor could then
Xoutput information about the interface as a Tcl command file to be read by
Xthe application when it starts up.
XSome current interface editors output C code which must then be compiled
Xinto the application [7]; unfortunately this approach requires an
Xapplication to be recompiled in order to change its interface (or,
Xalternatively, it requires a dynamic-code-loading facility).  If Tcl
Xwere used as the interface specification language then no recompilation
Xwould be necessary and a single application binary could support many
Xdifferent interfaces.
X
X5.  Communication Between Applications
X
XThe advantages of an embedded command language like Tcl become even
Xgreater if all of the tools in an environment are based on the same
Xlanguage.  First, users need only learn one basic command language;
Xto move from one application to another they need only learn the
X(few?) application-specific commands for the new application.  Second,
Xgeneric interface editors become possible, as described in the previous
Xsection.  Third, and most important in my view, Tcl can provide a means
Xof communication between applications.
X
XI have implemented a communication mechanism for X11 in the form of an
Xadditional Tcl command called "send".  For send to work, each Tcl
Xinterpreter associated with an X11 application is given a textual name,
Xsuch as "xmh" for an X mail handler or mx.foo.c for a window in which
Xmx is displaying a file named foo.c.  The send command takes two arguments:
Xthe name of an interpreter and a Tcl command to execute in that interpreter.
X"Send" arranges for the command to be passed to the process containing the
Xnamed interpreter; the command is executed by that interpreter and the
Xresults (return code and string) are returned to the application that
Xissued the "send" command.
X
XThe X11 implementation of send uses a special property attached to the
Xroot window.  The property stores the names of all the interpreters plus
Xa window identifier for each interpreter.  A command is sent to an interpreter
Xby appending it to a particular property in the interpreter's associated
Xwindow.  The property change is detected by the process that owns the
Xinterpreter; it reads the property, executes the command, and appends
Xresult information onto a property associated with the sending application.
XFinally, the sending application detects this change of property, reads
Xthe result information, and returns it as the result of the send command.
X
XThe send command provides a powerful way for one application to control
Xanother.  For example, a debugger could send commands to an editor to
Xhighlight the current source line as it single-steps through a program.
XOr, a user interface editor could use send to manipulate an application's
Xinterface directly: rather than modifying a dummy version of the
Xapplication's interface displayed by the interface editor, the interface
Xeditor could use send to modify the interface of a ``live'' application,
Xwhile also saving the configuration for a configuration file.  This would
Xallow an interface designer to try out the look and feel of a new interface
Xincrementally as changes are made to the interface.
X
XAnother example of using send is for changing user preferences.  If one
Xuser walks up to a display that has been configured for some other user,
Xthe new user could run a program that finds out about all the existing
Xapplications on the screen (by querying the property that contains their
Xnames), reads the new user's configuration file for each application, and
Xsends commands to that application to reconfigure it for the new user's
Xpreferences.  When the old user returns, he or she could invoke the same
Xprogram to restore the original preferences.
X
X"Send" could also be used to record interactive sessions involving multiple
Xapplications and then replay the sessions later (e.g.  for demonstration
Xpurposes).  This would require an additional Tcl command called trace;
Xtrace would take a single argument (a Tcl command string) and cause that
Xcommand string to be executed before each other command was executed in
Xthat interpreter.  Within a single application, trace could be used to record
Xeach Tcl command before it is executed, so that the commands could be replayed
Xlater.  In a multi-application environment, a recorder program could be built
Xusing send.  The recorder sends a trace command to each application to be
Xrecorded.  The trace command arranges for information to be sent back
Xto the recorder about each command executed in that application.  The
Xrecorder then logs information about which applications executed which
Xcommands.  The recorder can reexecute the commands by "send"-ing them
Xback to the applications again.  The trace command does not yet exist
Xin Tcl, but it could easily be added.
X
XSend provides a much more powerful mechanism for communication between
Xapplications than is available today.  The only easy-to-use form of
Xcommunication for today's applications is the selection or cut buffer:
Xa single string of text that may be set by one application and read by
Xanother.  Send provides a more general form of communication akin to
Xremote procedure call [3].  If all of an application's functionality is
Xmade available through Tcl, as described in Section 4, then send makes
Xall of each application's functionality available to other applications
Xas well.
X
XIf Tcl (and send) were to become widely used in window applications, I
Xbelieve that a better kind of interactive environment would arise,
Xconsisting of a large number of small specialized applications rather
Xthan a few monolithic ones.  Today's applications cannot communicate
Xwith each other very well, so each application must incorporate all
Xthe functionality that it needs.  For example, some window-based debuggers
Xcontain built-in text editors so that they can highlight the current
Xpoint of execution.  With Tcl and send, the debugger and the editor could
Xbe distinct programs, with each sending commands to the other as necessary.
XIdeally, monolithic applications could be replaced by lots of small
Xapplications that work together in exciting new ways, just as the UNIX
Xshells allowed lots of small text processing applications to be combined
Xtogether.  I think that Tcl, or some other language like it, will provide
Xthe glue that binds together the windowing applications of the 1990's.
X
X6.  Status and Performance
X
XThe Tcl language was designed in the fall of 1987 and implemented in the
Xwinter of 1988.  In the spring of 1988 I incorporated Tcl into the mx
Xeditor (which already existed, but with an inferior command language),
Xand also into a companion terminal emulator called Tx.  Both of these
Xprograms have been in use by a small user community at Berkeley for
Xthe last year and a half.  All of the Tcl language facilities exist as
Xdescribed above, except that the send command is still in prototype form
Xand trace hasn't been implemented.  Some of the features described in
XSection 4, such as menu and keystroke bindings, are implemented in mx, but
Xin an ad hoc fashion: Tcl is not yet integrated with a widget set.  I am
Xcurrently building a new toolkit and widget set that is based entirely on
XTcl.  When it is completed, I expect it to provide all of the features
Xdescribed in Section 4.  As of this writing, the implementation has barely
Xbegun.
X
XTable II shows how long it takes Tcl to execute various commands on two
Xdifferent workstations.  On Sun-3 workstations, the average time for simple
Xcommands is about 500 microseconds, while on DECstation 3100's the average
Xtime per command is about 160 microseconds.  Although mx does not currently
Xuse a Tcl command for each mouse motion event, the times in Table II suggest
Xthat this would be possible, even on Sun-3 workstations, without significant
Xdegradation of response.  For example, if mouse motion events occur 100 times
Xper second, the Tcl overhead for dispatching one command per event will
Xconsume only about 1-2% of a Sun-3 processor.
XFor the ways in which Tcl is currently used (keystroke and menu bindings
Xconsisting of a few commands), there are no noticeable delays associated
Xwith Tcl.  For application-specific commands such as those for the mx editor,
Xthe time to execute the command is much greater than the time required by
XTcl to parse it and call the command procedure.
X
XThe Tcl library is small enough to be used in a wide variety of programs, even
Xon systems without mechanisms for sharing libraries.  The Tcl code consists of
Xabout 7000 lines of C code (about half of which is comments).  When compiled
Xfor a Motorola 68000, it generates about 27000 bytes of object code.
X
X7.  Comparisons
X
XThe Tcl language has quite a bit of surface similarity to Lisp, except
Xthat Tcl uses curly braces or brackets instead of parentheses and no braces
Xare needed around the outermost level of a command.  The greatest difference
Xbetween Tcl and Lisp is that Lisp evaluates arguments by default, whereas
Xin Tcl arguments are not evaluated unless surrounded by brackets.  This
Xmeans that more typing effort is required in Tcl if an argument is to be
Xevaluated, and more typing effort is required in Lisp if an argument is
Xto be quoted (not evaluated).
XIt appeared to me that no-evaluation is usually the desired result in
Xarguments to a command language, so I made this the default in Tcl.
XTcl also has fewer data types than Lisp; this was done in order to simplify
Xthe interface between the Tcl library and an enclosing C application.
X
XThe Emacs editor is similar to Tcl in that it provides a framework that
Xcan be used to control many different application programs.  For example,
Xsubprocesses can be run in Emacs windows and users can write Emacs command
Xscripts that (a) generate command sequences for input to the applications
Xand (b) re-format the output of applications.  This allows users to embellish
Xthe basic facilities of applications, edit their output, and so on.
X
XThe difference between Emacs and Tcl is that the programmability is
Xcentralized in Emacs: applications cannot talk to each other unless Emacs
Xacts as intermediary (e.g.  to set up a new communication mechanism between
Xtwo applications, code must be written in Emacs to pass information back
Xand forth between the applications).  The Tcl approach is decentralized:
Xeach application has its own command interpreter and applications may
Xcommunicate directly with each other.
X
XLastly, it is interesting to compare Tcl to NeWS [9], a window system that
Xis based on the Postscript language.  NeWS allows applications to down-load
Xa window server in order to change the user interface and modify other
Xaspects of the system.  In a sense, this is similar to the "send" command in
XTcl, in that applications may send programs to the server for execution.
XHowever, the NeWS mechanism is less general than Tcl: NeWS applications
Xgenerate Postscript programs as output but they do not necessarily respond
Xto Postscript programs as input.  In other words, NeWS applications can
Xaffect each others' interfaces, by controlling the server, but they cannot
Xdirectly invoke each others' application-specific operations as they can
Xwith Tcl.
X
XTo summarize, the Tcl approach is less centralized than either the Emacs
Xor NeWS approaches.  For a windowing environment with large numbers of
Xindependent tools, I think the decentralized approach makes sense.
XIn fairness to Emacs, it's important to point out that Emacs wasn't designed
Xfor this environment, and that Emacs works quite nicely in the environment
Xfor which it was designed (ASCII terminals with batch-style applications).
XIt's also worth noting that direct communication between applications was
Xnot an explicit goal of the NeWS system design.
X
X8.  Conclusions
X
XI think that Tcl could improve our interactive environments in three general
Xways.  First, Tcl can be used to improve individual tools by providing them
Xwith a programmable command language; this allows users to customize tools
Xand extend their functionality.  Second, Tcl can provide a uniform command
Xlanguage across a range of tools; this makes it easier for users to program
Xthe tools and also allows tool-independent facilities to be built, such as
Xinterface editors.  Third, Tcl provides a mechanism for tools to control
Xeach other; this encourages a more modular approach to windowing applications
Xand makes it possible to re-use old applications in new ways.  In my opinion
Xthe third benefit is potentially the most important.
X
XMy experiences with Tcl so far are positive but limited.  Tcl needs a larger
Xuser community and a more complete integration into a windowing toolkit before
Xit can be fully evaluated.  The Tcl library source code is currently available
Xto the public in a free, unlicensed form, and I hope to produce a Tcl-based
Xtoolkit in the near future.
X
X9.  Acknowledgments
X
XThe members of the Sprite project acted as guinea pigs for the editor and
Xterminal emulator based on Tcl; without their help the language would
Xnot have evolved to its current state.  Fred Douglis, John Hartman,
XKen Shirriff, and Brent Welch provided helpful comments that improved the
Xpresentation of this paper.
X
X10.  References
X
X[1] Abelson, H.  and Sussman, G.J.
X    Structure and Interpretation of Computer Programs,
X    MIT Press, Cambridge, MA, 1985.
X
X[2] Adobe Systems, Inc.
X    Postscript Language Tutorial and Cookbook,
X    Addison-Wesley, Reading, MA, 1985.
X
X[3] Birrell, A.  and Nelson, B.
X    ``Implementing Remote Procedure Calls.''
X    ACM Transactions on Computer Systems,
X    Vol.  2, No.  1, February 1986, pp.  39-59.
X
X[4] Brodie, L.
X    Starting FORTH: An Introduction to the FORTH Language and
X        Operating System for Beginners and Professionals,
X    Prentice Hall, Englewood Cliffs, NJ, 1981.
X
X[5] Kernighan, B.W.  and Pike, R.
X    The UNIX Programming Environment,
X    Prentice Hall, Englewood Cliffs, NJ, 1984.
X
X[6] Kernighan, B.W.  and Ritchie, D.M.
X    The C Programming Language,
X    Second Edition,
X    Prentice Hall, Englewood Cliffs, NJ, 1988.
X
X[7] Mackey, K., Downs, M., Duffy, J., and Leege, J.
X    ``An Interactive Interface Builder for Use with Ada Programs,''
X    Xhibition Conference Proceedings, 1989.
X
X[8] Stallman, R.
X    GNU Emacs Manual,
X    Fourth Edition,
X    Version 17,
X    February 1986.
X
X[9] Sun Microsystems, Inc.
X    NeWS Technical Overview,
X    Sun Microsystems, Inc.
X    PN 800-1498-05, 1987.
X
END_OF_FILE
if test 41391 -ne `wc -c <'tcl6.1/doc/usenix.text'`; then
    echo shar: \"'tcl6.1/doc/usenix.text'\" unpacked with wrong size!
fi
# end of 'tcl6.1/doc/usenix.text'
fi
echo shar: End of archive 31 \(of 33\).
cp /dev/null ark31isdone
MISSING=""
for I in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 ; do
    if test ! -f ark${I}isdone ; then
    MISSING="${MISSING} ${I}"
    fi
done
if test "${MISSING}" = "" ; then
    echo You have unpacked all 33 archives.
    rm -f ark[1-9]isdone ark[1-9][0-9]isdone
else
    echo You still need to unpack the following archives:
    echo "        " ${MISSING}
fi
##  End of shell archive.
exit 0

exit 0 # Just in case...
--
Kent Landfield                   INTERNET: [e-mail]
Sterling Software, IMD           UUCP:     uunet!sparky!kent
Phone:    [phone]         FAX:      [phone]
Please send comp.sources.misc-related mail to [e-mail].