Neither the title of this paper, its abstract, nor even the name of the journal in which it appears clearly explain that it mainly discusses the programming language Scheme. A specialist in this area would probably know that this journal was formerly named Lisp and symbolic computation. However, the title of the paper is somewhat negative, and does not lead the potential reader to expect to learn something really practical.

Thus, I will describe the subject of this paper in my own way. In Scheme, as well as in other programming languages with dynamic typing, the great freedom enjoyed by the programmer has negative consequences: typing errors that would be easily caught at compile-time with a statically typed language like Ada are only detected at runtime. What is worse, such an error may remain undetected for a long time, if the part of the program where it occurs is seldom executed.

Thus, it is useful to develop static type checkers, which work on the source text and try to automatically compute the range of values or the generalized type taken by every expression. The technique is often known as abstract interpretation, and works by building sets of abstract values, associated with every expression in the program. This approach also works for checking that every function is called with the proper number of parameters, since this is a part of the type of the function.

The problem is made more complicated when functions accept variable numbers of parameters, which is similar to the concept of function name overloading encountered in languages like C++ or Java. The sets of abstract values are much more difficult to build, especially if one wants to avoid false error messages.

The authors consider the case of Scheme, extended with case-lambda expressions: in such an expression, a choice is made depending on the number of actual parameters of the lambda-expression that defines the function. Thus, a specific branch of the lambda-expression is executed only if the function was called with a specific number of parameters, except for the rest clause, executed when none of the previous cases was chosen.

The authors show that a generalization of the set-based analysis made by MrSpidey, the static debugger developed for Scheme, leads to unacceptable performances. They develop a different method, using “closure analysis set-based analysis,” which seems to be almost linear. This is demonstrated with a set of tests, although the programs used are purely caricatures. The bulk of the paper is devoted to the presentation of the constraint rules used as a basis for the static debugger. This paper is somewhat difficult to read, and a more algorithmic presentation could have been more pleasant.