Why Extern

Tcl/Tk is an easy languages to get started with. It's highly stable, works across multiple platforms, and because of Tk can be used to create cross-platform GUI applications.

eg. here is the Hello World program in a one line of code:

  pack [button .b -text "Hello World" -command exit]

The Bad News

Unfortunately once a Tcl application grows larger than a few files (or a few hundred procs) it becomes progressively more difficult to manage.

There are several reasons for this, but principly Tcl's dynamic nature hides most errors until runtime. ie. until individual lines of code are executed. Even basic constructs such as if, while, and foreach are not checked.

Static Checkers

The typical response is to employ static type-checkers,=. However these have several limitations. First, checkers must replicate Tcls code parsing logic. Also difficult is when built-in commands are redefined (eg. proc). Lastly, static checkers are of limited use in embedded applications, the very place where Tcl shines.

Code Coverage

The end result is that Tcl code really demands extensive code coverage testing, particularly after any updates. For example. If, during a re-factor, a proc is renamed or has it's arguments changed, the resulting breakage can be widespread and severe. Finding and fixing all such affected occurrences can be tedious, time-consuming and frustrating. In short, maintenance issues becomes a monkey on Tcl's back.

Prototypes

To address these issues, Wize adds the equivalent of C function prototypes to Tcl by way of the extern command. extern defines signatures which are used at compile time to warn of coding problems, particularly betwen modules. A second purpose of externs is enabling command-completion in editors such as Ted. Lastly, externs can be used to demand load code.

© 2008 Peter MacDonald