Despite the numerous advantages of Tcl/Tk, there are also a few shortcomings of the language which must be taken into consideration when writing scripts. Some of these problems can be overcome by adopting disciplined programming practices, while others may be corrected by extension packages, many of which are also freely available. This section outlines many of the potential drawbacks of Tcl/Tk in the context of the circuit editor GUI implementation.
Because Tcl scripts are interpreted instead of compiled, execution of the scripts will obviously be slower than an equivalent C or C++ implementation. However, as the implementation of the circuit editor progressed, it was discovered there were only two situations in which speed played a major factor -- the extraction of netlists and movement of multiple circuit elements. To alleviate the former problem, a feature known as dynamic netlist identification was implemented and is discussed in Section 3.6.1. The slowness resulting from the latter problem could have been corrected by moving only a rectangular outline enclosing the circuit elements being moved, but this feature was not yet implemented at the time of writing. Of course, the option to rewrite these slow operations in C and build a new Tcl interpreter is always possible should the need arise.
Another potential problem has to do with the fact that the simulator engine was already written in C++ and not Tcl. By adopting Tcl/Tk as the language for the GUI, we must establish some means of communication between the two different implementation languages so that the GUI can inform the simulator what circuit to simulate and the simulator could report the simulation results back to the GUI for presentation to the end user. Although there are ways of embedding Tcl/Tk within a C++ application, the decision was made to keep the GUI and the simulator modules distinct from one another and instead to link them together via a bidirectional pipe. Communication between the two modules would then take place using a well defined protocol. In addition to solving the inter-module communication problem, this physical separation of abstractions encourages (indeed, enforces) loose coupling between the GUI and the simulator engine, thereby resulting in a more flexible and orthogonal implementation. The details of this protocol are described in Chapter 5.
One of the more serious shortcomings of Tcl/Tk is the lack of
a rich set of data structures. The only true data types in
Tcl are strings and associative
arrays.
The string type is also
used to provide support for integers and floating point numbers and for
lists as well. The lack of aggregate data structures increases the
need for global variables as a means of inter-procedural and
inter-module communication in situations where procedural parameters are
not possible. This problem is compounded by the lack of namespaces
which can seriously compromise an effective modular design. As a
result, Tcl scripts do not scale very well.
However, there are several possible workarounds to these inherent
problems. In order to compensate for the lack of namespaces, a
prefixing scheme was devised for procedures and global variables which
would reduce the potential for clashes between variable and procedure
names across different modules. Also, several extension packages for
Tcl exist which offer better support for data abstraction and
enhanced scoping. Alternatively, algorithms involving a rich set of
data structures could be written in C and linked with the
Tcl core library.
As mentioned earlier, several freely available extensions to Tcl/Tk exist which help to overcome many of the above problems. However, the decision was made not to use them due to the relative volatility of Tcl/Tk during the implementation of the circuit editor GUI. During this time, Tk was undergoing a major revision from 3.6 to 4.0, which rendered some of the extension packages unusable due to the many backward incompatible changes introduced into the new version of Tk. While some of the extension packages bravely kept pace with the numerous changes to the Tcl/Tk core, other extension packages have adapted more slowly. However, as these packages are upgraded to adopt the new features of Tk 4.0 and become more mature, an effort may be made to reevaluate and possibly reimplement the GUI using one of these extension languages.