SCTGEN Scripting Language

February 23, 1995

At a recent design meeting, a considerable amount of time was spent discussing the exact nature of SCTGEN's configuration file. Between Stan muttering "... nothing procedural about it ..." and Karen crossing her fingers at me to ward off the demons invoked by my speaking of an "initialization script", I was tempted to turn to Dave and knock some sense into him by knocking him up side the head with a belaying pin (a nautical term, probably incorrect).

I'm at a loss to understand why everyone was so adamant that the SCTGEN configuration file not be a script. I would like to propose that the Tool Command Language (Tcl) be used as the scripting language for all phases of SCTGEN processing, from initialization to termination. Tcl is a shell-like command language

whose interpreter can be embedded in an application;
which can be extended with application-specific commands;
which is a mature, widely-used language;
and which includes support for object-oriented programming.

Using Tcl would benefit SCTGEN in the following ways:

Consistency - A single, scripting language would be used both for initial program configuration and to control the actual test data generation.
Flexibility - SCTGEN would become a user-programmable test data generator. Functionality normally hardcoded in C or C++ would become dynamically configurable by simply editing a Tcl script.
Power - (Skip this paragraph if you aren't a power user.) The standard Tcl extension, [incr Tcl] (i.e., Tcl++), adds C++-like classes, inheritance, polymorphism, and dynamic binding to Tcl. Do I need to expound further on the advantages of object-oriented support?
Portability - Tcl runs under a variety of operating systems: UNIX (SunOS and HP/UX), VxWorks, VMS, etc. Ports of Tcl to DOS, Windows, Windows NT (UNIX-killer), and Mac's are available.

Tcl is a small, but rich language that supports looping constructs, conditional statements, string manipulation, arithmetic, etc. It could be used in roles as simple as implementing a "database" for configuration parameters and in roles as complex as initiating and controlling the distribution of data generation tasks on multiple workstations. The discussion that follows focuses on using Tcl for the SCTGEN configuration file.

There's no software to write.

To read and execute the "initialization script" requires only 4 lines of code:

    #include  "tcl.h"
    Tcl_Interp  *interpeter ;

    interpreter = Tcl_CreateInterp () ;
    Tcl_EvalFile (interpreter, "configuration file name") ;

It's that simple. Setting the value of a configuration parameter in Tcl is done with the "set" command:

    set parameter value

Retrieving the value of a parameter from within C or C++ code is a one-liner:

    value = Tcl_GetVar (interpreter, "parameter", 0) ;

Tcl's associative arrays (i.e., arrays indexed by strings instead of integers) and/or [incr Tcl]'s classes provide the means for partitioning parameters into logical groups and for handling namespace problems.

Tcl-based applications are easily maintained and updated.

Imagine adding a new parameter to SCTGEN's configuration. If the configuration file was a data file, you would have to:

Modify the SCTGEN header file to declare a global variable that will contain the new parameter's value. Modifying the header file will most likely require that all of SCTGEN be recompiled.
Modify the configuration loading code to read and parse the new parameter's value. Depending on your data file format, existing configuration files may be rendered obsolete by these changes.
Update the code that will use the new parameter by #include'ing the header file and referencing the parameter's global variable.
Create a configuration data file containing the new parameter.

If the configuration file were a Tcl script, you would only have to:

Update the code that will use the new parameter:
```
    #include "tcl.h"
    char  *value ;
    ...
    value = Tcl_GetVar (interpreter, "parameter", 0) ;
    if (value == NULL)  value = default_value ;
```
By supplying a default value if the parameter is not specified, existing configuration files will remain usable.

Since the value returned by Tcl_GetVar() is a string, you may need to perform a numeric conversion; e.g.,
```
    integer = atoi (Tcl_GetVar (...)) ;
```
Add a "set" command to the configuration script:
```
    set parameter value
```

Which is preferable, a code-intensive, configuration data file or a simple configuration script?

"There's nothing procedural about initialization."
"A configuration file should not be executable."

Why and why not, respectively? When the gentle server running on the LZP rack answers a network connection request from a client, it loads a series of Tcl scripts that define the layouts of the various subsystem status blocks. For example, the DP status block is defined by the following Tcl commands:

    set dpstatus [Region #auto DPSTATUS -mapFunction mapSTS]
    #    MEDS status header.
    DefineStatusHeader $dpstatus
    #    DP information.
    $dpstatus Define tpceRequest
    $dpstatus Define dataSetSize
    $dpstatus Define transferSize
    $dpstatus Define dataSetName string 40
    $dpstatus Define targetHost string 40
    ... define the remaining fields in the status block ...

There's nothing much procedural about this Tcl code, except for, well ...

The first command causes gentle to map to the DP status block.
All status blocks have a standard, MEDS status header, so the definitions of the header fields were moved into a common Tcl procedure, DefineStatusHeader.
The Define method of the dpstatus object saves the field name and data type ("unsigned long" is the default) for future reference and computes the address of the field in the status block.
The procedural aspects of its configuration scripts
- made gentle dynamically configurable,
- avoided replication of common definitions, and
- provided a concise means of defining the fields in a status block.

With a script-based, configuration file, you don't have to make use of the scripting language's procedural capabilities. With a data-based, configuration file, you don't even have the option of using procedural capabilities, should they prove useful or necessary.

Performance, Performance, Performance.

Tcl was clocked at over 6000 commands per second on a DEC workstation back in the late 1980's. At this rate, you wouldn't notice or be bothered by any difference in speed between the processing of a configuration data file and the interpretation of a configuration script. If you're still not convinced, think of all the script-programmable, text editors in the world: Emacs, TPU, and about a zillion PC-based editors. Few people, except for the occasional JOVE malcontent, complain about their response time.