What is Tcl?
Tcl, or Tool Command Language, is a an elegant, versatile, feature-rich, simple-to-learn yet very powerful industrial-strength open-source programming language and development platform. It is renowned for its stability and utility, and its emphasis on providing a cross-platform programming API makes it an ideal choice for an enormous variety of programming jobs.
Tcl is one of the only languages that can is convenient for both the smallest and largest programming tasks, without ever having to ask, "Is it overkill to use Tcl here", or "If this code gets bigger, will Tcl scale?". Whenever a shell script might be used, it Tcl could just as easily be used. On the other hand, entire web ecosystems and mission-critical control and testing systems are also written in Tcl. Tcl excels in all these roles due to the ingenious syntax of the language, the unique programming paradigm exposed at the script level, and the unparalleled engineering that has gone into the design of the Tcl internals.
Tcl syntax is described in just a dozen rules. There are no reserved words and no specialized syntax for control structures, conditionals, and so on. Tcl's control and branching operations are, like everything else in a Tcl program, commands. For example, if is a command that in its simplest form takes a conditional expression to test and a block of code to be executed if the condition is true. It could be rewritten in a Tcl script where some modified version of if is desired.
Tcl has all the features needed to rapidly create useful programs in any field of application, on a wide variety of platforms, and supporting any character set. Whatever the platform, Tcl is probably already there.
In addition to being a programming language, Tcl is also a cross-platform C library. If you've been looking into glib , APR , or NSPR , or qtcore , you might end up using Tcl not for its scripting capability, but to provide the features you've been looking for in a truly portable C library.
Tcl is simple to learn, and fun to use.
set x abc puts "A simple substitution: $x\n"
set y set x "def" puts "Remember that set returns the new value of the variable: X: $x Y: $y\n"
set z {set x "This is a string within quotes within braces"} puts "Note the curly braces: $z\n"
set a "set x {This is a string within braces within quotes}" puts "See how the set is executed: $a" puts "\$x is: $x\n"
set b "[set y {This is a string within braces within quotes}]" # Note the \ escapes the bracket, and must be doubled to be a # literal character in double quotes puts "Note the \\ escapes the bracket:\n \$b is: $b" puts "\$y is: $y"
Joe Mistachkin 2006-06-08: Based on my previous research (when I had access to the actual hardware), modern versions of Tcl have not been ported to HP MPE/ix. Please correct me if this is inaccurate.
see Who Uses Tcl
Ulrich Albrecht: One more story, same implication: A couple of years ago I was working at the technical university of Aachen (Germany) on a robot simulation and path-planning system, including fast collision detection. The core functionality was included in a C++ class hierarchy describing robot parts and kinematics, with a lot of C libraries from other sources mixed in. The code was to perform on a real robot controller (a PPC-machine running vxworks), SGI Irix (MIPS), Sun Solaris (SPARC), Linux (Intel) and eventually MS Windows (Intel), so we could not include any platform specific stuff. With the exception of vxworks though - where the real thing was moving - we thought we should have a GUI with a virtualization and visualization of the robot and its environment. Tcl/Tk looked good, because it was the only package that was as portable, flexible and extensible as we needed. I wrote an OpenGL-widget for Tk and a Tcl-to-C++ command-wrapper for every C++ class I needed to construct and control at runtime, and ended up with a robotics-enabled wish I could feed all kinds of szenarios and interact with. I can really say that 1. portability was not a big issue, because the core C/C++-libraries were OS-independent and Tcl/Tk as well as OpenGL were properly ported, 2. performance wasn't either, because the critical parts were nice, dirty compiled C/C++, 3. usability was very good because of the robust interactive Tcl-interpreter we could use for free, 4. the Tk-part performed and looked a lot better and more OS-consistent than anything I've since seen in Java...
We even run this stuff in MS Internet Explorer (using the Tk-Plugin) for demonstration purposes.
Nearly forgot: Porting the code to MS Windows was not the problem - it was the makefiles that nearly drove us mad.
See Tcl heritage
Tcl was originally developed as a reusable command language for experimental computer-aided design (CAD) tools. The interpreter was implemented as a C library that could be linked into any application. Because it is very easy to add new functions to the Tcl interpreter, it is an ideal embeddable scripting language. (See Tcl Chronology for more history.)
Tcl could be roughly described as a cross-breed between:
Tcl is a homoiconic language whose design was motiviated by the idea that there would be as little core syntax as possible, with as many other needed facilities as possible implemented as commands. Fundamentally, Tcl is nothing but a script parser, a substitution engine, and a command dispatcher.
(See Tcl heritage for more ancestry.)
Tcl programs are sometimes called "scripts" because the programs do not need to be compiled into a binary form before running them, but the Tcl performs JIT compilation transparently, so Tcl does not suffer from the performance penalty associated with traditional interpreters.
You can even use other Tcl extensions like 'Expect' to control command line programs from a GUI.
For many people, their first acquaintance with Tcl is as a component of another software program. Examples include Expect, Cisco IOS.
As of Tcl 8.4, the only interpreters that you really need to think about are tclsh, tclkit, and (on some platforms) wish, as Tcl provides the ability to dynamically load any of the other extensions during runtime. In fact, many of the extensions have been dropping the building and installing of custom executables due to this.
Tcl is a weakly-typed dynamic language. In Tcl, everything is a string, but that fact just scratches the surface.
Tcl semantics allows code to be seen as data, as with Lisp (see code is data).
slebetman: Does tcl really do JIT? When was it/will it be introduced? 8.5? 8.6?
NEM: No. Certainly not JIT in the sense of compiling to native code. It compiles to byte-code on-demand, which could be seen as "just in time", but JIT usually means native.
DKF: We've talked (usually at conferences after a few beers) about doing JIT, and the key problem is that it takes quite a lot of development effort to do and would (potentially, depending on details) need to be re-implemented for every architecture that Tcl supports. On the other hand, doing just x86 would handle a very large fraction of what's actually deployed...
FB: A plausible solution would be to use LLVM as an intermediary target instead of the current bytecode format. Then LLVM would JIT-compile to the native architecture using its available backends (it can also degrade gracefully to interpreter mode). But it likely involves a lot of work.
Sarnold Actually that's what Jacl does by compiling commands to Java bytecode that the JVM can JIT-compile. A similar thing could be achieved using a .NET implementation.
What are the advantages of LLVM over JVM/.NET ? (apart from giving more performance and integration with C code, which are already known) Wouldn't it be overkill to write a JIT-compiling Tcl from scratch for LLVM, since both Tcl implementations exist for the JVM and .NET/Mono?
FB I thought that Jacl was only an interpreter, but you're right since it now includes the TJC compiler. From what I know, the most interesting features of LLVM are global and runtime optimizations, and a runtime compiler architecture that can be used to provide Critcl-like features. Very interesting given the glue nature of Tcl. Starting from TJC to build a LLVM-based compiler might give a head start.