[attachment=1459]
SEMINAR REPORT ON TOOL COMMAND LANGUAGE
Introduction to Tcl
TCL/TKs (Tool Command Language/Tool Kit) strength is that it is a small, interpreted, language that can be embedded, access graphics and system features, and is extensible. It also is multiplatform and has very wide support. It can be downloaded on the NET, and it runs TCL scripts for backend processing. TCL is a language, called the Tool Command Language. TK is a set of extensions or "widgets"(the actual official designation) that happened to be written by TCLâ„¢s author to add graphic capability to his TCL interpreter they include things like list boxes, entry boxes, radio buttons, check boxes, etc.... In fact, prior to TCL/TK 8.0, TCL was at version 7.3, and TK was at version 4, as I recall. In a way, TCLâ„¢s relationship to TK is kind of like VBs relationship to activex(which ALSO has controls as mentioned above, and are sold as one package). In fact, a VB user can program for a long time without realizing that he or she is using activex components all over the place.
Tcl was originally intended to be a reusable command language. Its developers had been creating a number of interactive tools, each requiring its own command language. Since they were more interested in the tools themselves than the command languages they would employ, these command languages were constructed quickly, without regard to proper design.
After implementing several such "quick-and-dirty" command languages and experiencing problems with each one, they decided to concentrate on implementing a general-purpose, robust command language that could easily be integrated into new applications. Thus Tcl (Tool Command Language) was born.
Since that time, Tcl has been widely used as a scripting language. In most cases, Tcl is used in combination with the Tk ("Tool Kit") library, a set of commands and procedures that make it relatively easy to program graphical user interfaces in Tcl.
One of Tcl's most useful features is its extensibility. If an application requires some functionality not offered by standard Tcl, new Tcl commands can be implemented using the C language, and integrated fairly easily. Since Tcl is so easy to extend, many people have written extension packages for some common tasks, and made these freely available on the internet.

Scripting: Higher Level Programming For 21st Century

Scripting languages such as Perl and Tcl represent a very different style of programming than system programming languages such as C or JavaTM. Scripting languages are designed for "gluing" applications; they use typeless approaches to achieve a higher level of programming and more rapid application development than system programming languages. Increases in computer speed and changes in the application mix are making scripting languages more and more important for applications of the future.
Introduction
For the last fifteen years a fundamental change has been occurring in the way people write computer programs. The change is a transition from system programming languages such as C or C++ to scripting languages such as Perl or Tcl. Although many people are participating in the change, few people realize that it is occurring and fewer people know why it is happening. Scripting languages will handle many of the programming tasks of the next century better than system programming language.
Scripting languages are designed for different tasks than system programming languages, and this leads to fundamental differences in the languages. System programming languages were designed for building data structures and algorithms from scratch, starting from the most primitive computer elements such as words of memory. In contrast, scripting languages are designed for gluing: they assume the existence of a set of powerful components and are intended primarily for connecting components together. System programming languages are strongly typed to help manage complexity, while scripting languages are typeless to simplify connections between components and provide rapid application development uages.
Scripting languages and system programming languages are complementary, and most major computing platforms since the 1960's have provided both kinds of languages. The languages are typically used together in component frameworks, where components are created with system programming languages and glued together with scripting languages. However, several recent trends, such as faster machines, better scripting languages, the increasing importance of graphical user interfaces and component architectures, and the growth of the Internet, have greatly increased the applicability of scripting languages. These trends will continue over the next decade, with more and more new applications written entirely in scripting languages and system programming languages used primarily for creating components.
System programming languages
In order to understand the differences between scripting languages and system programming languages, it is important to understand how system programming languages evolved. System programming languages were introduced as an alternative to assembly languages. In assembly languages, virtually every aspect of the machine is reflected in the program. Each statement represents a single machine instruction and programmers must deal with low-level details such as register allocation and procedure calling sequences. As a result, it is difficult to write and maintain large programs in assembly language.
By the late 1950's higher level languages such as Lisp, Fortran, and Algol began to appear. In these languages statements no longer correspond exactly to machine instructions; a compiler translates each statement in the source program into a sequence of binary instructions. Over time a series of system programming languages evolved from Algol, including such languages as PL/1, Pascal, C, C++, and Java. System programming languages are less efficient then assembly languages but they allow applications to be developed much more quickly. As a result, they have almost completely replaced assembly languages for the development of large applications.
System programming languages differ from assembly languages in two ways: they are higher level and they are strongly typed. The term "higher level" means that many details are handled automatically so that programmers can write less code to get the same job done. For example:
¢ Register allocation is handled by the compiler so that programmers need not write code to move information between registers and memory.
¢ Procedure calling sequences are generated automatically: programmers need not worry about moving arguments to and from the call stack.
¢ Programmers can use simple keywords such as while and if for control structures; the compiler generates all the detailed instructions to implement the control structures.
On average, each line of code in a system programming language translates to about five machine instructions, compared to one instruction per line in assembly language (in an informal analysis of eight C files written by five different people, It was found that the ratio ranged from about 3 to 7 instructions per line in a study of numerous languages Capers Jones found that for a given task, assembly languages require about 3-6 times as many lines of code as system programming languages). Programmers can write roughly the same number of lines of code per year regardless of language, so system programming languages allow applications to be written much more quickly than assembly language.
The second difference between assembly language and system programming languages is typing. I use the term "typing" to refer to the degree to which the meaning of information is specified in advance of its use. In a strongly typed language the programmer declares how each piece of information will be used and the language prevents the information from being used in any other way. In a weakly typed language there are no a priori restrictions on how information can be used: the meaning of information is determined solely by the way it is used, not by any initial promises.1
Modern computers are fundamentally typeless: any word in memory can hold any kind of value, such as an integer, a floating-point number, a pointer, or an instruction. The meaning of a value is determined by how it is used: if the program counter points at a word of memory then it is treated as an instruction; if a word is referenced by an integer add instruction then it is treated as an integer; and so on. The same word can be used in different ways at different times.

Different tools for different tasks
A scripting language is not a replacement for a system programming language or vice versa. Each is suited to a different set of tasks. For gluing and system integration, applications can be developed 5-10x faster with a scripting language; system programming languages will require large amounts of boilerplate and conversion code to connect the pieces, whereas this can be done directly with a scripting language. For complex algorithms and data structures, the strong typing of a system programming language makes programs easier to manage. Where execution speed is key, a system programming language can often run 10-20x faster than a scripting language because it makes fewer run-time checks.
In deciding whether to use a scripting language or a system programming language for a particular task, consider the following questions:
¢ Is the application's main task to connect together pre-existing components
¢ Will the application manipulate a variety of different kinds of things
¢ Does the application include a graphical user interface
¢ Does the application do a lot of string manipulation
¢ Will the application's functions evolve rapidly over time
¢ Does the application need to be extensible
"Yes" answers to these questions suggest that a scripting language will work well for the application. On the other hand, "yes" answers to the following questions suggest that an application is better suited to a system programming language:
¢ Does the application implement complex algorithms or data structures
¢ Does the application manipulate large datasets (e.g. all the pixels in an image) so that execution speed is critical
¢ Are the application's functions well-defined and changing slowly
Scripting and system programming are symbiotic. Used together, they produce programming environments of exceptional power: system programming languages are used to create exciting components which can then be assembled using scripting languages. For example, much of the attraction of Visual Basic is that system programmers can write ActiveX components in C and less sophisticated programmers can then use the components in Visual Basic applications. In Unix it is easy to write shell scripts that invoke applications written in C. One of the reasons for the popularity of Tcl is the ability to extend the language by writing C code that implements new commands.
Scripting is on the rise
Scripting languages have existed for a long time, but in recent years several factors have combined to increase their importance. The most important factor is a shift in the application mix towards gluing applications. Three examples of this shift are graphical user interfaces, the Internet, and component frameworks.
The growth of the Internet has also popularized scripting languages. The Internet is nothing more than a gluing tool. It doesn't create any new computations or data; it simply makes a huge number of existing things easily accessible. The ideal language for most Internet programming tasks is one that makes it possible for all the connected components to work together, i.e. a scripting language. For example, Perl has become popular for writing CGI scripts and JavaScript is popular for scripting in Web pages. Another reason for the increasing popularity of scripting languages is improvements in scripting technology. Scripting technology is still relatively immature even today. For example, Visual Basic isn't really a scripting language; it was originally implemented as a simple system programming language, then modified to make it more suitable for scripting. Future scripting languages will be even better than those available today. Scripting technology is still relatively immature even today. For example, Visual Basic isn't really a scripting language; it was originally implemented as a simple system programming language, then modified to make it more suitable for scripting. Future scripting languages will be even better than those available today.
Today the number of applications written in scripting languages is much greater than the number of applications written in system programming languages. Scripting languages are already a major force in application development and their market share will increase in the future.
Scripting languages have actually generated significant software reuse. They use a model where interesting components are built in a system programming language and then glued together into applications using the scripting language. This division of labor provides a natural framework for reusability. Components are designed to be reusable, and there are well-defined interfaces between components and scripts that make it easy to use components. For example, in Tcl the components are custom commands implemented in C; they look just like the builtin commands so they are easy to invoke in Tcl scripts. In Visual Basic the components are ActiveX extensions, which can be used by dragging them from a palette onto a form. Scripting languages represent a different set of tradeoffs than system programming languages. They give up execution speed and strength of typing relative to system programming languages but provide significantly higher programmer productivity and software reuse. This tradeoff makes more and more sense as computers become faster and cheaper in comparison to programmers. System programming languages are well suited to building components where the complexity is in the data structures and algorithms, while scripting languages are well suited for gluing applications where the complexity is in the connections. Gluing tasks are becoming more and more prevalent, so scripting will become an even more important programming paradigm in the next century than it is today.
Scripting languages represent a different set of tradeoffs than system programming languages. They give up execution speed and strength of typing relative to system programming languages but provide significantly higher programmer productivity and software reuse. This tradeoff makes more and more sense as computers become faster and cheaper in comparison to programmers. System programming languages are well suited to building components where the complexity is in the data structures and algorithms, while scripting languages are well suited for gluing applications where the complexity is in the connections. Gluing tasks are becoming more and more prevalent, so scripting will become an even more important programming paradigm in the next century than it is today.

The birth of Tcl
The Tcl scripting language grew out on design tools for integrated circuits at the University of California at Berkeley in the early 1980's.
The notion of embeddability is one of the most unique aspects of Tcl, and it led to the following three overall goals for the language:
¢ The language must be extensible: it must be very easy for each application to add its own features to the basic features of the language, and the application-specific features should appear natural, as if they had been designed into the language from the start.
¢ The language must be very simple and generic, so that it can work easily with many different applications and so that it doesn't restrict the features that applications can provide.
¢ Since most of the interesting functionality will come from the application, the primary purpose of the language is to integrate or "glue together" the extensions. Thus the language must have good facilities for integration.
The conclusion that to reduce the resource requirements by building large systems out of reusable components. If most of the complexity of a system was in the components, and it could carry the components forward from system to system, perhaps it could build large powerful systems .
The additional resources provided by Sun make major improvements to Tcl and Tk. Scott Stanton and Ray Johnson ported Tcl and Tk to Windows and the Macintosh, so that Tcl became an outstanding cross-platform development environment; today, more than two-thirds of Tcl downloads are for Windows.


An Introduction to Tcl Syntax
For a scripting language, Tcl has a simple syntax.
cmd arg arg arg
A Tcl command is formed by words separated by white space. The first word is the name of the command, and the remaining words are arguments to the command.
$foo
The dollar sign ($) substitutes the value of a variable. In this example, the variable name is foo.
[clock seconds]
Square brackets execute a nested command. For example, if you want to pass the result of one command as the argument to another, you use this syntax. In this example, the nested command is clock seconds, which gives the current time in seconds.
"some stuff"
Double quotation marks group words as a single argument to a command. Dollar signs and square brackets are interpreted inside double quotation marks.
{some stuff}
Curly braces also group words into a single argument. In this case, however, elements within the braces are not interpreted.
\
The backslash (\) is used to quote special characters. For example, \n generates a newline. The backslash also is used to "turn off" the special meanings of the dollar sign, quotation marks, square brackets, and curly braces.
A Little Example
Below is a Tcl command that prints the current time. It uses three Tcl commands: set, clock, and puts. The set command assigns the variable. The clock command manipulates time values. The puts command prints the values.
set seconds [clock seconds]
puts "The time is [clock format $seconds]"
Note that you do not use $ when assigning to a variable. Only when you want the value do you use $. The seconds variable isn't needed in the previous example. You could print the current time with one command:
puts "The time is [clock format [clock seconds]]"
Grouping and Substitution
The Tcl syntax is used to guide the Tcl parser through three steps: argument grouping, result substitution, and command dispatch.
1. Argument grouping. Tcl needs to determine how to organize the arguments to the commands. In the simplest case, white space separates arguments. As stated earlier, the quotation marks and braces syntax is used to group multiple words into one argument. In the previous example, double quotation marks are used to group a single argument to the puts command.
2. Result substitution. After the arguments are grouped, Tcl performs string substitutions. Put simply, it replaces $foo with the value of the variable foo, and it replaces bracketed commands with their result. That substitutions are done after grouping is crucial. This sequence ensures that unusual values do not complicate the structure of commands.
3. Command dispatch. After substitution, Tcl uses the command name as a key into a dispatch table. It calls the C procedure identified in the table, and the C procedure implements the command. You also can write command procedures in Tcl. There are simple conventions about argument passing and handling errors.
Another Example
Here is another example:
set i 0
while {$i < 10} {
puts "$i squared = [expr {$i*$i}]"
incr i
}
Here, curly braces are used to group arguments without doing any substitutions. The Tcl parser knows nothing special about the while command. It treats it like any other command. It is the implementation of the while command knows that the first argument is an expression, and the second argument is more Tcl commands. The braces group two arguments: the boolean expression that controls the loop and the commands in the loop body.
We also see two math expressions: the boolean comparison and multiplication. The while command automatically evaluates its first argument as an expression. In other cases you must explicitly use the expr command to perform math evaluation.
Command Dispatch
Lastly, Tcl calls something else to do the hard work. We've seen that Tcl uses expr to perform math functions, puts to handle output functions, and set to assign variables. These Tcl commands are implemented by a C procedure that has registered itself with Tcl. The C command procedures take the string arguments from the Tcl command and return a new string as their result. It is very easy to write C command procedures. They can do everything from accessing databases to creating graphical user interfaces. Tcl, the language, doesn't really know what the commands do. It just groups arguments, substitutes results, and dispatches commands.
One other Example
Here is the factorial procedure:
proc fac {x} {
if {$x < 0} {
error "Invalid argument $x: must be a positive integer"
} elseif {$x <= 1} {
return 1
} else {
return [expr {$x * [fac [expr {$x-1}]]}]
}
}
Setting up Environment Variables
The binaries and libraries of Tcl/Tk and its extensions such as blt etc are generally installed under /usr/bin and /usr/lib. If this is not the case (i.e. they are compiled but not installed under /usr) , we need to set up a few environment variables .
e.g., If the master directory is ~/tcl then
setenv TCL_LIBRARY ~/tcl/itcl/lib/tcl7.4
setenv TK_LIBRARY ~/tcl/itcl/lib/tk4.0
setenv ITCL_LIBRARY ~/tcl/itcl/lib/itcl2.0
setenv ITK_LIBRARY ~/tcl/itcl/lib/itk2.0
setenv IWIDGETS_LIBRARY ~/tcl/itcl/lib/iwidgets2.0
setenv EXPECT_LIBRARY ~/tcl/expect/lib
setenv BLT_LIBRARY ~/tcl/blt/lib
Our search path should be set up to pick up the correct binaries for tclsh, wish or itkwish etc. Make sure you include the pathnames in your set path in our .login or .cshrc or .profile file
tclsh
The starting point to writing your own Tcl scripts is to familiarise ourself with Tcl syntax and learn the core Tcl commands. Take the first step by typing tclsh at command level in your commandtool/shelltool/xterm. Shell will invoke tclsh to prompt sign will change to % to indicate tclsh is ready to read your Tcl commands from the keyboard and pass them to the Tcl interpreter for evaluation.
Every Tcl command consists of one or more words, the first of which is the name of the C function to be invoked by the interpreter. The rest of the words in the command are passed as arguments for the C procedure. The C function provided by the Tcl library. Tcl library contains functions to provide a full set of programming features to Tcl such as variables, control flow etc. Use the Basics of Tcl application to explore these. we can write your own functions as well and register them with Tcl interpreter. The following simple commands to test and get a flavour of Tcl:
expr 10 * 5
tclsh will print 50 and prompt you again.
expr is a core Tcl application for carrying out arithmetic operations. expr returns 1 for true and 0 for false for Boolean values when it evaluates relational operations..
Try:
% puts "Hi there"
You will get:
Hi There
%
Each Tcl command is separated either by a newline or a semicolon. Backslash in a command tells Tcl that the command continues in the next line.
Try
% puts "Hi there going to \
next line "
You will get:
Hi there going to next line
%
Type
% exit
to quit tclsh.
wish
Most applications would want to use Tcl as the basis for scripting and assembling their modules together but create their own commands based on one or more extensions of Tcl, in particular Tk, the toolkit of commands for building window-based Tcl applications. Without Tk, Tcl remains yet another scripting language.
Tk (and all Tcl) commands can be invoked within the tk windowing shell wish.
Try (at command level of commandtool/shelltool/xterm):
wish
The result will look like:

The wish mainwindow is placed within the xterm that invoked it.
Tcl and Tk on World Wide Web
Compressed tar file of Tcl/Tk manual pages in Hypertext Markup Language are available from ftp.ftp.funet.fi/pub/languages/tcl/contrib/docs. The Tcl/Tk Reference Guide (latex document) can also be fetched from the same source.
Tcl Built-In Commands
NAME
for - ``For'' loop
for start test next body
DESCRIPTION
For is a looping command, similar in structure to the C for statement. The start, next, and body arguments must be Tcl command strings, and test is an expression string. The for command first invokes the Tcl interpreter to exe-cute start. Then it repeatedly evaluates test as an expression; if the result is non-zero it invokes the Tcl
interpreter on body, then invokes the Tcl interpreter on next, then repeats the loop. The command terminates when test evaluates to 0. If a continue command is invoked
within body then any remaining commands in the current execution of body are skipped; processing continues by invoking the Tcl interpreter on next, then evaluating
test, and so on. If a break command is invoked within body or next, then the for command will return immediately. The operation of break and continue are similar to
the corresponding statements in C. For returns an empty string.
NAME
case - Evaluate one of several scripts, depending on a
given value
case string in patList body patList body ...
case string in {patList body patList body ...}
DESCRIPTION
The case command is obsolete and is supported only for backward compatibility. At some point in the future it may be removed entirely. You should use the switch command instead.
The case command matches string against each of the patList arguments in order. Each patList argument is a list of one or more patterns. If any of these patterns matches string then case evaluates the following body argument by passing it recursively to the Tcl interpreter and returns the result of that evaluation. Each patList argument consists of a single pattern or list of patterns.
Each pattern may contain any of the wild-cards described under string match. If a patList argument is default, the corresponding body will be evaluated if no patList matches string. If no patList argument matches string and no default is given, then the case command returns an empty string.
Two syntaxes are provided for the patList and body arguments. The first uses a separate argument for each of the patterns and commands; this form is convenient if substitutions are desired on some of the patterns or commands.
The second form places all of the patterns and commands together into a single argument; the argument must have proper list structure, with the elements of the list being the patterns and commands. The second form makes it easy to construct multi-line case commands, since the braces around the whole list make it unnecessary to include a backslash at the end of each line. Since the patList arguments are in braces in the second form, no command or variable substitutions are performed on them; this makes the behavior of the second form different than the first form in some cases.
NAME
append - Append to variable
append varName value value value ...
DESCRIPTION
Append all of the value arguments to the current value of variable varName. If varName doesn't exist, it is given a value equal to the concatenation of all the value arguments. This command provides an efficient way to build up long variables incrementally. For example, ``append a$b'' is much more efficient than ``set a $a$b'' if $a is long.
NAME
catch - Evaluate script and trap exceptional returns
catch script varName
DESCRIPTION
The catch command may be used to prevent errors from aborting command interpretation. Catch calls the Tcl interpreter recursively to execute script, and always returns a TCL_OK code, regardless of any errors that might occur while executing script. The return value from catch is a decimal string giving the code returned by the Tcl interpreter after executing script. This will be 0 (TCL_OK) if there were no errors in script; otherwise it will have a non-zero value corresponding to one of the exceptional return codes (see tcl.h for the definitions of code values). If the varName argument is given, then it gives the name of a variable; catch will set the variable to the string returned from script (either a result or an error message).
catch catches all exceptions, including those generated by break and continue as well as errors.
NAME
array - Manipulate array variables
array option arrayName arg arg ...
DESCRIPTION
This command performs one of several operations on the variable given by arrayName. Unless otherwise specified for individual commands below, arrayName must be the name of an existing array variable. The option argument determines what action is carried out by the command. The legal options (which may be abbreviated) are:
array anymore arrayName searchId
Returns 1 if there are any more elements left to be processed in an array search, 0 if all elements have already been returned. SearchId indicates which search on arrayName to check, and must have been the return value from a previous invocation of
array startsearch. This option is particularly useful if an array has an element with an empty name, since the return value from array nextelement won't indicate whether the search has been completed.
array donesearch arrayName searchId
This command terminates an array search and destroys all the state associated with that search. SearchId indicates which search on arrayName to destroy, and must have been the return value from a previous invocation of array startsearch. Returns an empty string.
array exists arrayName
Returns 1 if arrayName is an array variable, 0 if there is no variable by that name or if it is a scalar variable.
array get arrayName pattern
Returns a list containing pairs of elements. The first element in each pair is the name of an element in arrayName and the second element of each pair is the value of the array element. The order of the pairs is undefined. If pattern is not spec ified, then all of the elements of the array are included in the result. If pattern is specified, then only those elements whose names match pattern (using the glob-style matching rules of string match) are included. If arrayName isn't the name of an array variable, or if the array contains no elements, then an empty list is returned.
array names arrayName pattern
Returns a list containing the names of all of the elements in the array that match pattern (using the globstyle matching rules of string match). If pattern is omitted then the command returns all of the element names in the array. If there are no (matching) elements in the array, or if arrayName isn't the name of an array variable, then an empty string is returned.
array nextelement arrayName searchId
Returns the name of the next element in arrayName, or an empty string if all elements of arrayName have already been returned in this search. The searchId argument identifies the search, and must have been the return value of an array startsearch
command. Warning: if elements are added to or deleted from the array, then all searches are automatically terminated just as if array donesearch had been invoked; this will cause array nextelement operations to fail for those searches.
array set arrayName list
Sets the values of one or more elements in array Name. list must have a form like that returned by array get, consisting of an even number of elements. Each odd-numbered element in list is treated as an element name within arrayName, and the following element in list is used as a new value for that array element.
array size arrayName
Returns a decimal string giving the number of elements in the array. If arrayName isn't the name of an array then 0 is returned.
array startsearch arrayName
This command initializes an element-by-element search through the array given by arrayName, such that invocations of the array nextelement command will return the names of the individual elements in the array. When the search has been completed, the array donesearch command should be invoked. The return value is a search identifier that must be used in array nextelement and array donesearch com- mands; it allows multiple searches to be underway simultaneously for the same array.
NAME
puts - Write to a file
puts -nonewline fileId string
DESCRIPTION
Writes the characters given by string to the file given by fileId. FileId must have been the return value from a previous call to open, or it may be stdout or stderr to refer to one of the standard I/O channels; it must refer to a file that was opened for writing. If no fileId is specified then it defaults to stdout. Puts normally outputs a newline character after string, but this feature may be suppressed by specifying the -nonewline switch.
Output to files is buffered internally by Tcl; the flush command may be used to force buffered characters to be output.
NAME
gets - Read a line from a file gets fileId varName
DESCRIPTION
This command reads the next line from the file given by fileId and discards the terminating newline character. If varName is specified then the line is placed in the variable by that name and the return value is a count of the number of characters read (not including the newline). If the end of the file is reached before reading any charac- ters then -1 is returned and varName is set to an empty string. If varName is not specified then the return value will be the line (minus the newline character) or an empty string if the end of the file is reached before reading any characters. An empty string will also be returned if a line contains no characters except the newline, so eof may have to be used to determine what really happened. If the last character in the file is not a newline character then gets behaves as if there were an additional newline character at the end of the file. FileId must be stdin or the return value from a previous call to open; it must refer to a file that was opened for reading. Any existing end-of-file or error condition on the file is cleared atthe beginning of the gets command.
The Tcl War

Tcl was not designed to be a serious programming language. It was designed to be a "scripting language", on the assumption that a "scripting language" need not try to be a real programming language. So Tcl doesn't have the capabilities of one. It lacks arrays; it lacks structures from which you can make linked lists. It fakes having numbers, which works, but has to be slow. Tcl is ok for writing small programs, but when you push it beyond that, it becomes insufficient.
Tcl is very slow. Tcl stores arrays as strings, making vector-ref take time linear in the number of elements. Tcl's associative arrays ("array variables") are implemented as hash tables, but the only key type is strings, making this facility very slow as well.
> Tcl has a peculiar syntax that appeals to hackers because of it simplicity.
But Tcl syntax seems strange to most users.
> If Tcl does become the "standard scripting language", users will curse it for
years--the way people curse Fortran, MSDOS, Unix shell syntax, and
other de facto standards they feel stuck with.
But Tcl has (simulated) lexically scoped local variables,
while many scripting languages (eg, elisp or perl4) have only
dynamically scoped variables. Tcl allows new control-flow
structures to be coined, which is an important structuring
primitive
The Nine Rules of Tcl Nobody Seems to Bother to Read thatâ„¢s why it feel problematic

1) a script is broken into commands at newline and semicolon
2) command evaluation proceeds by simple dispatch on the first
word of a command after substitutions described in 3-9
3) a command is broken into words at whitespace
4-8) if the first character of a word is " or {,
do " or { quotation to form the word,
if a word contains [, $ or \,
do command, variable, or backslash substution into the word
9) if a # is encountered as the first character of the first word
of a command, the characters up to and including the
following newline are ignored as a comment
True, some of the subtleties aren't captured here, especially that
rules 4-8 can gobble up whitespace, and some \ behavior. But the
above 9 rules[2], subtelties and all, with rules 3-9 being applied
on a single level scan, are all there is to lexing and parsing Tcl,
and they are all right on the Tcl(n) man page.
Even though it can probably be interpreted, it looks to me as a compiled
language. As such, I think it makes people working on medium to
large projects happy because the compiler helps everything stay
efficient, consistant, and maintainable. Tcl does hardly anything
in this area. However, Tcl makes it possible to do small things
quickly, and to write programs that can be customized by endusers with very little effort.
Tcl: award-winning software
In the spring of 1998 there was a wonderful news that Tcl had won two major awards. The first is the ACM Software System Award, awarded each year for "a software system that has had a lasting influence". Past winners of the award include such seminal systems as the TCP/IP protocols, the first spreadsheets, the first relational databases, the World-Wide Web, Unix, PostScript, and Smalltalk. The second award was the USENIX Software Tools User Group (STUG) Award, given each year in recognition of an outstanding software tool.


BIBLIOGRAPHY
¢ http//computerhope.com
¢ http//opengroup.com
¢ http//citeseer.nj.nec.com
¢ http//bitd.clrc.ac.uk
¢ http//tcl.vandeburg.org


TABLE OF COTENTS :
Introduction to Tcl
¢ Scripting : Higher Level Programming For 21st Century
The Birth of Tcl
An Introduction to Tcl Syntax
¢ Setting up Environment Variables
Tcl Built in Commands
The Tcl War