The following paper was originally published in the Proceedings of the Fifth Annual Tcl/Tk Workshop Boston, Massachusetts, July 1997

Assertions for the Tcl Language

Jonathan E. Cook Department of Computer Science New Mexico State University Las Cruces, NM

For more information about USENIX Association contact: 1. Phone: 510 528-8649 2. FAX: 510 548-5738 3. Email: [email protected] 4. WWW URL: http://www.usenix.org

Assertions for the Tcl Language

Jonathan E. Co ok

Department of Computer Science

New Mexico State University

Las Cruces, NM 88003

[email protected]

http://www.cs.nmsu.edu/jcook

Abstract over an aggregate data structure, which in Tcl is a list

or array.For this, we provide universal and existential

Assertions, even as simple as the C assert macro,

quanti ers for b oth lists and arrays, not only for indi-

o er important self-checking properties to programs, and

vidual elements but for sequences of elements as well.

improve the robustness of software when they are used.

Section 2 describ es our assertion commands and

This paper describes AsserTcl, an assertion package

their meaning and use, and Section 3 describ es the

for the Tcl programming language. Our assertions take

quanti ers and their use. Section 4 describ es the in-

the form of commands in the program text, and cover

terface for controlling the evaluation of assertions. Sec-

point assertions about the computation state, assertions

tion 5 presents some pragmatic issues in adding asser-

about procedure input values and the return value, and

tions to the Tcl language, and describ es the metho ds we

assertions about the values that variables may take on

used to implement assertions. Section 6 presents some

over their whole lifetime. In addition, universal and

examples in using the assertions and quanti ers. Sec-

existential quanti ers areprovided for both lists and ar-

tion 7 evaluates the p erformance of a Tcl program that

rays, not only for individual elements, but for sequences

uses assertions. Finally, Section 8 concludes with some

of elements as wel l.

observations ab out assertions, the Tcl language and its

future, and p ossible enhancements to the language to

make it easier to develop debugging and analysis to ols.

1 Intro duction

Assertions|declarati ve annotations to a program

2 Assertion Commands

that describ e some prop erty ab out the program and

its state|are useful to ols in pro ducing robust software.

Our assertions for Tcl are commands that use a nor-

Most programming languages are not designed to in-

mal Tcl expression as an assertion ab out some p ortion

clude assertions, with the notable exception b eing Eif-

of the program. The four assertion commands that we

fel [3], but e orts have pro duced annotation languages

have added to Tcl are:

for Ada [2], C [5], Awk [1], and others. This pap er de-

scrib es assertions for the Tcl programming language [4].

 assert is an assertion ab out the current state of

Tcl is a p opular, interpreted, \scripting" language.

computation. It is evaluated at the p oint it o ccurs

It is now b eing used to build large tens and hundreds

in the source;

of KLOCs systems, many of which are b eing used in

 assume is an assertion ab out the input values to

the commercial sector. Unfortunately, few to ols exist

a pro cedure. It is evaluated up on entry to a pro-

that help one build robust Tcl application s.

cedure;

This is where assertions t in. Assertions help de-

velop ers write robust co de by o ering dynamic check-

 assure is an assertion ab out the output and return

ing of program prop erties, and enhancing the program's

values of a pro cedure. It is evaluated up on exit

testability. Our AsserTcl package provides assertions

from a pro cedure;

for the Tcl programming language. The assertions take

the form of commands in the program text, and cover

 always is an assertion ab out part of the state space

p oint assertions ab out the computation state, assertions

i.e., variables of the program. It must always

ab out pro cedure input values and the return value, and

hold, and is evaluated each time one of the vari-

assertions ab out the values that variables may takeon

ables it dep ends on changes value.

over their whole lifetime, singly or in relation to other

These commands are summarized in Table 1.

variables.

The form for each of these assertions is:

In addition, many desirable assertions in Tcl will b e

General Form of Assertions

assert-cmd expr ?fail-action? ?-default also?

Each assertion evaluates expr at some p oint or p oints in the execution of the program. If the

expression evaluates to true nonzero, no action is taken. If false 0, fail-action is taken if

it is sp eci ed, otherwise a general exception o ccurs. The fail-action can use break, continue,

or return. Sp ecifying the -default also ag will force the general exception to o ccur after

doing the fail-action.

Sp eci c Assertion Commands

assert expr ?fail-action? ?-default also?

Point assertion: evaluates expr at the p oint of its sp eci cation, each time the program reaches

that p oint.

assume expr ?fail-action? ?-default also?

Pro cedure entry assertion: evaluates expr at the b eginning of a pro cedure, and should b e

an assertion ab out the input parameters of the pro cedure and global variables used. This

command should b e placed at the top of the pro cedure b o dy, just after any global statements,

so that it can b e seen as part of the pro cedure sp eci cation.

assure expr ?fail-action? ?-default also?

Pro cedure exit assertion: evaluates expr just b efore returning from a pro cedure, and should

b e an assertion ab out the return value of a pro cedure, and any side e ects global variables

mo di ed of the pro cedure. Note that this command do es not need to b e placed at the end of

the pro cedure, and should b e placed at the top, after any assume s, so it can b e seen as part

of the pro cedure sp eci cation. The values of the input parameters at the time of pro cedure

in variables, one for each parameter. The return value of invo cation are available through *

the pro cedure is available through the return val variable.

always varlist expr ?fail-action? ?-default also?

Program state assertion: evaluates expr every time one of the variables in varlist changes.

The variables in varlist should b e a subset of  the variables in expr, and the expression

should b e a statement ab out the relationships that must hold or values those variables can

take on. The assertion exists for the lifetime of the variables in varlist, and the always

assertion can b e used in pro cedure b o dies for lo cal variables, as well as for global variables.

Table 1: The four basic assertion commands for Tcl.

assert-cmd expression [failure-action] [-default also] execute the default action after executing the failure-

action; this can b e used to print out detailed messages

where assert-cmd is one of assert , assume ,or assure .

in the failure-action, while still ab orting the program.

The always assertion is:

For assertions ab out and in pro cedures, the value

of the input parameters at the time of invo cation is use-

always varlist expression [failure-action] [-default also]

ful, b ecause the parameters maybechanged during ex-

In b oth forms, expression is the Tcl expression to b e

ecution of the pro cedure, and an assertion would no

evaluated. For the assertion to b e satis ed, this expres-

longer have access to the original values. For this, we

sion must evaluate to true nonzero. For the always

in, where param is create variables of the form param

assertion, varlist is a list of variables to activate the as-

the name of each parameter to the pro cedure. These

sertion on, such that when any one of them changes, the

* in variables are set with the input value of the pa-

expression is evaluated. It do es not have to include all

rameter, and do not change over the execution of the

1

the variables in the always , but should not include any

pro cedure. They can b e used in any assertion inside

variables not in the expression.

that pro cedure.

Failure-action is an optional Tcl statement blo ck

For assure assertions, the return value of the pro ce-

that, if supplied, will b e executed if the assertion fails.

dure must also b e available. We provide this through

If no failure-action is sp eci ed, the default action of pro-

avariable return val. This variable is set in evaluating

ducing a general exception o ccurs, printing out the na-

an assure , when the pro cedure is exiting. While it can

ture of the failed assertion and ab orting the program.

p otentially clash with an existing variable name as can

-default also is an optional ag that, if sp eci ed, will

in variables, if the variable is lo cal, no harmful the *

e ects will o ccur since the pro cedure is exiting, though

the original value will not b e accessible in the assure .

1

For example, there may b e transient states for one of the

The only case where a problem will o ccur is if return val

variables that should b e ignored.

is a global variable and is declared so in the pro cedure.

General Form of Quanti ers

quanti er-cmd item-varname[s] data-struct expr

A quanti er command evaluates expr for all items or item sequences in the data structure list

or array, and returns 1 if the expression is true nonzero for the sp eci ed quanti catio n over

the data structure. If item-varname is singular, that variable takes on the value of each item

in the list or index in the array as the quanti ed expression is evaluated. If item-varname

is a list, the variable names in the list take on successivevalues in the data structure, such

that the order of names in the parameter is the order of values in the data structure. If more

item-varname's are sp eci ed than there are memb ers in the data structure, the quanti er

returns 1.

Sp eci c Quanti er Commands

lall item[s] list expr

List universal: evaluates expr for all items or item sequences, and returns 1 if the expression

is true over the whole list, and 0 otherwise.

lexists item[s] list expr

List existential: evaluates expr for all items or item sequences, and returns 1 if the expression

is true for any item item sequence in the list, and 0 otherwise.

rall index[es] array-name expr

Array universal: evaluates expr for all indices or index sequences, and returns 1 if the ex-

pression is true over the whole array, and 0 otherwise. The index list can b e prep ended with

any sorting ags that 'lsort' accepts.

rexists index[es] array-name expr

Array existential: evaluates expr for all indices or index sequences, and returns 1 if the

expression is true for any index index sequence in the array, and 0 otherwise. The index

list can b e prep ended with any sorting ags that 'lsort' accepts.

Table 2: The four quanti er commands for Tcl.

For this case, wewould strongly suggest that return val of the pro cedure interface. As such, they should app ear

2

is not a very go o d name for a global variable. as the rst statements in the pro cedure b o dy, after any

global statements which are also part of the interface.

The always assertion, when it is used as an assertion

2.1 Usage Conventions

ab out global state, should app ear at the top of the given

Tcl mo dule that has the global state variables. If it is

Assertions in a program b ecome part of the do cu-

b eing used as an assertion ab out the internal state of a

mentation of the program, its b ehavior, and its inter-

pro cedure, it should app ear at the top of the pro cedure

nal interfaces b etween mo dules and pro cedures. This

body, after any assume and assure assertions, or after

suggests that some of the assertion forms should have

the variables are created.

standard placements in the program.

The assert assertion is a p oint assertion. It should

b e used at any p oint in the Tcl program where the

3 Quanti er Commands

programmer can make a succinct declarative statement

ab out the state of the program, or where they wantto

The two basic aggregate data typ es in Tcl are the

ensure that a variable or variables contain the prop er

list and array. Assertions may often take the form of

data. At the top or b ottom of a lo op b o dy it can act as

describing the prop erties of a list or an array; for exam-

aloopinvariant.

ple, sp ecifying that a list contains all p ositivenumeric

For pro cedure interfaces, the assume and assure as-

items. In these cases, universal and existential quanti-

sertions should b e used. These assertions capture the

ers over lists and arrays are useful. Our commands for

assumptions that the pro cedure makes on its parame-

these take the general form of:

ters and any global variables used, and the assurances

of its return values or of any global variables changed.

quanti er fitemjindex listgfarray-namejlistg

The assertions in e ect b ecome part of the declaration

expression

Our four quanti ers are lal l and lexists for list universal

2

There are safer ways for naming input parameter and return

and existential quanti cation, and ral l and rexists for

value variables, such as using an array with named elements, like

array quanti cation . These commands are summarized

assertreturn for the return value. It was felt that a construct

in Table 2. The rst parameter to a quanti er is a list of

such as this would simply b e to o cluttering for b eing able to

succinctly read an assertion expression.

item names or index names dep endent on whether a list

Assertion Control Interface

assertcl disable ?al ljprocjvar? ?al ljproclistjvarlist?

Disables all assertion checking, assertion checking for the given list of pro cs, or assertion

checking for the given list of variables. The keyword al l can b e used in place of a pro cedure

or variable list, indicating all pro cedures or all variables, resp ectively.

assertcl enable ?al ljprocjvar? ?al ljproclistjvarlist?

Enables all assertion checking, assertion checking for the given list of pro cs, or assertion

checking for the given list of variables. The keyword al l can b e used in place of a pro cedure

or variable list, indicating all pro cedures or all variables, resp ectively.

Table 3: The control interface for AsserTcl.

or array is used. These names are variables that take to sp ecify integer indices in a decreasing order. This

on successivevalues of the items in a list indices into an syntax is a bit cumb ersome and unfortunate, but it is

array. The quanti ers have their general meaning: the the b est we can do.

expressions in lal l and ral l must hold for all sequences of

items indices, and the expressions in lexists and rexists

4 Controlling Assertion Checking

must hold for at least one sequence of items indices.

A quanti er returns 0 for false and 1 for true.

We recognize that assertion checking can b e costly

For example, to sp ecify that all elements of a nu-

in some instances, in terms of p erformance. This can

meric list are p ositive, the quanti er

b e esp ecially true with quanti ers over large data struc-

lall i $list {$i >= 0}

tures, and the cost can b e somewhat hidden at times.

For example, if a pro cedure is called for each item in

is used. Here the item list is only one item, i. One item,

a data structure, and that pro cedure has an assertion

however, cannot b e used for relations among items, such

ab out the whole data structure, the assertion e ectively

as sp ecifying that a list is sorted. For this, a quanti er

2

turns an O n computation into one that is O n .

suchas

We exp ect that when a program is nally released

lall {i1 i2} $list {$i1 <= $i2}

for use, disablin g the assertion pro cessing is desirable.

Even during system development, as some p ortions of

is used, where i1 and i2 take on successivevalues of

the system b ecome reliable, it may b e desirable to turn

items in the list. On a list of ve items, for example,

o assertion pro cessing for those p ortions.

there would b e four pairs of items to compare in the

In AsserTcl, assertions are controlled through the

quanti er. If a list is shorter than the numb er of items

assertcl control interface. Table 3 shows the commands

asked for, the quanti er returns true 1.

that are allowed by this interface.

Array quanti ers work the same way, except for

Assertion control is provided at the pro cedure level,

one problem|the order of indices to an arrayis

3

variable level for always , and the global level. The

unconstrained, so quanti ers over sequences of ele-

global level simply disables all assertion pro cessing, and

ments are less obvious. Still, in many uses of arrays,

is e ected by issuing the command

programmers do have a sequence of indices in mind, and

it would not b e unreasonable to sp ecify that an arrayis

assertcl disable all

sorted, like

for disabli ng, and with the enable keyword for enabling.

rall {i1 i2} Arr {$Arr$i1 <= $Arr$i2}

By using the proc keyword and providing a list of

pro cedure names, assertion disabling can b e done p er

For this, our quanti ers pro cess the indices in an lsort'ed

pro cedure. The command

sequence; that is, we use an index sequence returned by

4

[lsort [array names Arr]], in this example. However,

assertcl disable proc P1 P2 P3

lsort by default is an ASCI I string sort, and if the indices

are numeric, this will give the wrong order. For this, our

would disable assertion checking for the three named

index list can takeany ags that lsort takes, and we pass

pro cedures. Other assertion pro cessing would still take

these on to lsort.Thus, the ab ove quanti er would b e

place, provided that global assertion checking had not

changed to

b een disabled. The keyword al l in place of a list of

rall {-integer -decreasing i1 i2} Arr \

pro cedure names disables assertion checking for all pro-

{$Arr$i1 <= $Arr$i2}

cedures.

A similar use of the var keyword disables pro cess-

3

ing any always assertions for the sp eci ed variables; if a

In Tcl, arrays are asso ciative, and any string can b e an index

into an array.

given always assertion still relies on other enabled vari-

4

ables, however, it will b e pro cessed when those variables

Of course, a quanti er using only one index do es not call

lsort, since there is no order needed.

change. The keyword al l in place of a list indicates all and catching any returned exceptions. If the expression

variables with always assertions. itself generates an exception an error or a user-de ned

Even with global-level assertion disabling , an over- exception, assert passes this back to the enclosing con-

head of checking the control variables is still paid. Thus, text. If the assertion fails, assert by default generates its

for a situation such as nal release of the software, a own exception using the return command. If the assert

nul lassertcl package that declares empty assertion com- has an asso ciated failure-action,however, that action

mands is available. Requiring this package in place of will b e uplevel'ed rather than generating an exception.

the regular assertcl package source leaves just the call The assume command is really just an alias for the

of an empty pro cedure as the only overhead. assert command, implemented as a pro cedure that up-

Section 7 analyzes the run-time p erformance of these level's an assert call. This do es not quite t the def-

various levels of assertion checking. inition of an assume b eing evaluated at the start of a

For removing virtually all overhead of using asser- pro cedure invo cation, since if the assume statementis

tions, our future work is exp ected to include making a not placed at the b eginning of the pro cedure b o dy like

program pro cessor that will comment and uncomment we suggest, it will not b e evaluated at the start. The

assertion commands automatically. This will allow vir- alternativewould b e to prepro cess the pro cedure b o dy

tually no overhead except for comment-skipping to ex- and move the assume 's, but this would involve some

ist in a released program, while still allowing the asser- serious syntactic analysis. For now, our decision is to

tions to remain as do cumentation, and to b e reactivated forego this step and rely on conventional placementof

if needed. the assume commands.

For implementing the always assertion, the Tcl trace

command is used, which allows registration of a pro ce-

5 Implementing Tcl Assertions

dure to call each time a variable is written reads are

also traceable. The always assertion creates a uniquely

The main Tcl command that enables the addition

named pro cedure that evaluates the expression in the

of assertion commands is the uplevel command, which

assertion and pro cesses any exceptional conditions and

evaluates a script in a di erent context; thus a pro ce-

a failure-action, if there is one. This pro cedure is then

dure can b e passed an expression or even a blo ckof

attached to eachvariable sp eci ed in the varlist param-

statements, and it can evaluate those in the context of

eter using the trace command.

its caller, thus making the pro cedure lo ok like a com-

mand in its caller's context.

The other main Tcl feature that we use is the ability

5.2 Assure: The Hard One

to rename an internal command and replace it with our

Implementing the assure command is quite a bit dif-

own pro cedure. We implementaproc pro cedure that

ferent and more involved. For this command, wedo

acts as a front-end pro cessor to the real proc command.

need to mo dify the pro cedure b o dy. Due to the return

Our front-end searches the pro cedure b o dy for assertion

command b eing a not-so-general exception generating

commands, and do es the following two things if it nds

mechanism, we do not and cannot globally replace the

any.

return command, but we pro cess the pro cedure's b o dy

1. The b o dy of the pro cedure gets prep ended with

and replace each return in a pro cedure with our own as-

statements that copy parameter values to a corre-

sertReturn pro cedure, if the pro cedure b eing pro cessed

sp onding param in variable. This gives access to

has any assure 's. The assertReturn pro cedure evalu-

the input values regardless of whether the pro ce-

ates the assure 's, and then e ects a real return from

dure mo di es the real parameter variables. Only

the calling pro cedure.

in variables that are used are copied. those param

Replacing the return command can cause some prob-

lems and incompatibil i ties with existing Tcl b ehavior,

2. Each return statement in the pro cedure gets

but only under well-de ned circumstances. The prob-

replaced with our own assertReturn statement.

lem stems from the fact that return is not simply a

Ours takes care of evaluating the assure 's for that

command that returns a value from a pro cedure, but

pro cedure, and then returning from the pro cedure.

rather a mechanism for generating exceptions. The ex-

After these two op erations on the pro cedure b o dy are

ception generated byareturn is passed by Tcl to the

done, we then call the normal proc command, so that

context of the caller of the pro cedure that the return

Tcl registers the pro cedure. The implementation of as-

command is in. But when we replace the return with

sure is explained in more detail b elow.

our own pro cedure, we add a layer of pro cedure call,

so that now the context that gets the exception is our

caller, not our caller's caller, as it should b e. And return

5.1 Assert, Assume, and Always: The

cannot b e uplevel'ed, b ecause of the way the call stack

Easy Ones

is pro cessed in Tcl.

Nevertheless, for Tcl co de that simply uses return

The assert command is implemented in the straight-

in the normal fashion of returning a value from a

forward manner of a pro cedure that acts like a com-

mand, i.e., uplevel'ing the expression to b e evaluated

5

pro cedure, replacing the command with our own do es A pro cedure that returns the quotient and remainder of

a divide op eration:

not break any Tcl b ehavior, and allows us to evaluate

any assure 's and then e ect a real return.



The lexical replacementofreturn with assertReturn

 divmod: returns a two-element list of quotient

is not done globally or universally.We only do this in

 and remainder

the b o dy of a pro cedure that is using assure s, so that



any other use of return is not a ected. Furthermore,

proc divmod {dividend divisor} {

 simply test for numeric value

we only replace a return call that b egins on its own line

assume {$dividend + 1 > $dividend}

white space excluded. This not only o ers simple and

 also, make sure non-zero divisor

quick replacement, avoiding complex syntactic pro cess-

assume {$divisor + 1 != 1}

ing, but o ers an \out" to a programmer who needs to

 must return the correct quotient and remainder

use return to throw an arbitrary exception in a pro ce-

assure {[lindex $return_val 0]*$divisor_in+ \

dure using assure s|they can hide the return from our

[lindex $return_val 1] == $dividend_in}

pro cessing by using a construct suchas

 procedure body

set quot [expr $dividend / $divisor]

if 1 { return -code $Exception ... }

set rem [expr $dividend  $divisor]

return [list $quot $rem]

Since this return do es not b egin its own line, our re-

}

placement metho d will ignore it.

The error command can also b e used to return from

Assert that all list elements are p ositive:

a pro cedure, but since this metho d is not interceptable

assert {[lall item $list {$item>=0}]}

due to the ab ove-mentioned limitation s on the return

command, we make no e ort to catch this command.

Assert that a list contains an element \Jon":

In [4], it is recommended that error not b e used except

assert {[lexists item $list {"Jon" == $item}]}

for true errors, in any case.

Assert that a list is sorted:

6 Examples assert {[lall {i1 i2} $list {$i1 <= $i2}]}

Assert that an array contains the value 42:

This section presents a few simple examples to give

a avor for what assertions in Tcl lo ok like and can do.

assert {[rexists i Arr {$Arr$i == 42}]}

Assert that an integer-indexed array is sorted:

A p oint assertion ab out variables x and y:

assert {[rall {-integer i1 i2} Arr \

assert {$x>4 && $x<$y+2}

{$Arr$i1 <= $Arr$i2}]}

A p oint assertion that simply prints a warning and do es

Of course, an arbitrary Tcl pro cedure can b e called in

not ab ort the program:

an assertion though it should not have side e ects!,

assert {$x>4 && $x<$y+2} {

so a pro cedure that checks the consistency of a more

puts "Assert failed: x:$x y:$y"

complex data structure can b e used, like:

}

assert {[lall cust $CustomerList \

An assertion ab out some global variables over the life

{[CheckCustRecord $cust]} {

of the program:

puts "Warning: Customer is malformed -- $cust"

}

always NumUsers {$NumUsers>=1&&\

$NumConnected > $NumUsers}

which asserts that a list of customer records are all con-

sistent, but only prints a warning if it is not.

Note that this assertion only gets checked

when N umU ser s changes, not when N umC onnected

changes.

7 Performance Evaluation

While assertions serve as unambiguous, written-

A simple pro cedure declaration with interface asser-

tions:

down, declarative sp eci cations of a program b ehavior,

their comp elling reason of existence is that they can

proc square {x} {

be evaluated at run-time, providing increased assurance

assume {$x+1 > $x} ; tests for numeric value

that a program's b ehavior is correct.

assure {$return_val == $x_in * $x_in}

Run-time evaluation of assertions do es not come for

set x [expr $x * $x]

free, of course. They add extra pro cessing to a program

return $x

}

and can add signi cant increases in program execution

time. For example, in the case of an assertion using lal l ,

5

the expression must b e evaluated over the whole list to

A pro cedure return \exception" is the only one that can b e

passed up one extra level. evaluate the assertion. If it is in a lo op, each iteration

eight of the thirteen pro cedures results in p erformance

Assertion

that is faster than the global assertcl disable al l; this

Con guration Tcl 7.6 Tcl 8.0a2

happ ens b ecause the pro cedure disabling actually skips

full assertions 97.53 48.16

inserting any assertion pro cessing in the b o dy of the

-P1 79.43 39.32

disabled pro cedures. Thus, if the time-critical pro ce-

-P2 78.12 38.64

dures are disabled in this manner, the other pro cedures

-P1,P2,P4 62.17 28.51

can still check assertions, and the p erformance remains

-P3 35.91 23.63

good.

all disabled 3.69 2.87

For the list quanti ers, allowing the commands to

-P1-8 2.56 2.29

use list names rather than lists would improve their pro-

6

nullpackage 1.14 0.73

cessing time immensely. However, this usage would not

comment-out 0.95 0.66

b e consistent with the normal Tcl list commands, so we

chose to leave the calling interface as using a list. How-

ever, wemay decide to change this, or supp ort b oth, in

Table 4: Performance of assertions

the future.

on Tcl 7.6 and Tcl 8.0a2

8 Conclusion

of the lo op pro cesses the whole list, p otentially making

2

an O n op eration b ecome O n .

In this pap er we presented AsserTcl, an assertion

This overhead can b e controlled during development

package for the Tcl programming language. We feel that

and testing through the judicious enabling and disabling

assertions will make the development of robust systems

of assertions in pro cedures and variables, as explained

easier. At the same time, we hop e to use this founda-

in Section 4.

tion for future research exploring more ideas in asser-

Here we present some p erformance numb ers for a

tions for programming languages, and for evaluating the

small Tcl program develop ed using assertions. The pro-

e ectiveness of assertions.

gram was a non-interactive, sto chastic Petri net simu-

Tcl is an evolving language, and the next version

lator, and made heavy use of arrays. The program con-

will have namespaces, which will b e akin to packages or

sisted of thirteen pro cedures, all of which had assertions

mo dules. Earlier work on Ada packages [2] and Ei el

in them. Two pro cedures used the lal l quanti er in their

ob jects [3] have shown that mo dules presentinteresting

assertions. The program did not contain any always as-

issues in developing e ective assertions for them. In

sertions. The program was 177 source lines, excluding

addition, ob ject oriented extensions to Tcl exist, and

comments and brace-only lines, and had 16 assertions.

these can provide a platform for exploring issues ab out

We ran the program using b oth Tcl 7.6 and Tcl

assertions for classes and ob jects.

8.0a2, on an UltraSparc running Solaris. Table 4 shows

In developing this package, some limitations were

the p erformance of a Tcl program over various con g-

encountered that could b e ameliorated by adding some

urations of assertion checking. Eachvalue is the mean

functionality to the Tcl core language. Our suggestions

of 5 runs, timed using the Unix time command. Rows

are:

with `-P' con gurations have assertion checking dis-

abled for the sp eci ed pro cedures, but enabled for ev-

1. Extend the exception generating capability of the

erything else. The last line in the table was the running

return command so that it is p ossible to throw

time of the program with all assertion statements hand-

an exception to a sp eci ed level, rather than al-

commented out of the program. This represents the

ways the caller. This would enable the true re-

lower b ound on running time.

placement of the return command enabling other

As can b e seen, full assertion checking carries a high

debugging packages, and would generalize the ex-

price for this particular example. It runs almost 100

ception mechanism.

times slower on Tcl 7.6, and almost 75 times slower on

2. Extend the info command with access to a pro ce-

Tcl 8.0. Disablin g various pro cedures reduces the time

dure's current line numb er when executing and

by considerable amount, with the disabling of assertions

le name. This is also a feature that would en-

in P3 cutting the execution time byover half on Tcl 8.0,

able more functional debugging packages. The

and almost two-thirds on Tcl 7.6.

info level command could b e extended to provide

The two metho ds of disablin g assertion checking, us-

the line numb er currently b eing executed in that

ing assertcl disable al l or using the nul lassertcl package

level, and a command suchasinfo procprocName

b oth show go o d p erformance relative to the commented-

could b e added that would return the le name

out p erformance. The nul lassertcl package p erformance

and the b eginning line numb er of the pro cedure

is within 20 on Tcl 7.6 and within 11 on Tcl 8.0,

de nition.

indicating that it is deployable technology|with an in-

teractive Tk program, an 11 overhead would not b e

6

A simple test with a 20-element list showed an order of mag-

noticeable in most instances.

nitude in sp eed di erence.

An interesting note is that disabling assertions in

Availability

AsserTcl is, and hop efully will remain, a Tcl-

only package, to ensure the b est p ortability and ease

of installation and use. It is freely available at

http://www.cs.colorado.edu/jco ok/TclTk.

Acknowledgements

Iwould like to thank Professor Mikhail Auguston

for discussing asp ects of assertions for programming lan-

guages, and to Professor David Rosenblum for rst turn-

ing me on to assertions. Many thanks to the anonymous

reviewers of this pap er as well. Their suggestions im-

proved it greatly.

REFERENCES

[1] M. Auguston, S. Banerjee, M. Mamnani, G. Nabi, J. Re-

infelds, U. Sarkans, and I. Strnad. A Debugger and As-

sertion Checker for the Awk Programming Language. In

Proc. International Conference on Software Engineering:

Education and Practice, Dunedin, New Zealand, 1996.

[2] David Luckham. Programming with Speci cations: An

introduction to Anna, a language for specifying Ada pro-

grams. Texts and Monographs in Computer Science.

Springer-Verlag, New York, 1990.

[3] Bertrand Meyer. Object-Oriented Software Construc-

tion. Prentice Hall, New York, 1988.

[4] John K. Ousterhout. Tcl and the Tk Toolkit. Profes-

sional Computing Series. Addison-Wesley, Reading, MA,

1994.

[5] David S. Rosenblum. A Practical Approach to Program-

ming with Assertions. IEEE Transactions on Software

Engineering, 1995.