DrScheme is a programming environment for Scheme. It fully integrates a graphicsenriched editor, a parser for multiple variants of Scheme, a functional read-eval-print loop, and an algebraic printer. The environment is especially useful for students, because it has a tower of syntactically restricted variants of Scheme that are designed to catch typical student mistakes and explain them in terms the students understand. The environment is also useful for professional programmers, due to its sophisticated programming tools, such as the static debugger, and its advanced language features, such as units and mixins. Beyond the ordinary programming environment tools, DrScheme provides an algebraic stepper, a context-sensitive syntax checker, and a static debugger. The stepper reduces Scheme programs to values, according to the reduction semantics of Scheme. It is useful for explaining the semantics of linguistic facilities and for studying the behavior of small programs. The syntax checker annotates programs with font and color changes based on the syntactic structure of the program. On demand, it draws arrows that point from bound to binding occurrences of identifiers. It also supports α-renaming. Finally, the static debugger provides a type inference system that explains specific inferences in terms of a value-flow graph, selectively overlaid on the program text.

There is significant room for improving users' experiences with model checking tools. An error trace produced by a model checker can be lengthy and is indicative of a symptom of an error. As a result, users can spend considerable time examining an error trace in order to understand the cause of the error. Moreover, even state-of-the-art model checkers provide an experience akin to that provided by parsers before syntactic error recovery was invented: they report a single error trace per run. The user has to fix the error and run the model checker again to find more error traces.

The Hindley/Milner let-polymorphic type inference system has two different algorithms: one is the de facto standard Algorithm W that is bottom-up (or context-insensitive), and the other is a "folklore" algorithm that is top-down (or context-sensitive). Because the latter algorithm has not been formally presented with its soundness and completeness proofs, and its relation with the W algorithm has not been rigorously investigated, its use in place of (or in combination with) W is not well founded. In this article, we formally define the context-sensitive, top-down type inference algorithm (named "M"), prove its soundness and completeness, and show a distinguishing property that M always stops earlier than W if the input program is ill typed. Our proofs can be seen as theoretical justifications for various type-checking strategies being used in practice.

Previous methods have generally identified the location of a type error as a particular program point or the program subtree rooted at that point. We present a new approach that identifies the location of a type error as a set of program points (a slice) all of which are necessary for the type error. We identify the criteria of completeness and minimality for type error slices. We discuss the advantages of complete and minimal type error slices over previous methods of presenting type errors. We present and prove the correctness of algorithms for finding complete and minimal type error slices for implicitly typed higher-order languages like Standard ML.

To improve the quality of type error messages in functional programming languages, we propose four techniques which influence the behaviour of constraint-based type inference processes. These techniques take the form of externally supplied type inference directives, precluding the need to make any changes to the compiler. A second advantage is that the directives are automatically checked for soundness with respect to the underlying type system. We show how the techniques can be used to improve the type error messages reported for a combinator library. More specifically, how they can help to generate error messages which are conceptually closer to the domain for which the library was developed. The techniques have all been incorporated in the Helium compiler, which implements a large subset of Haskell.

. Traditional type inference and type checking algorithms work well with correctly typed programs, but their results when given programs containing type errors can be unpredictable. This leads to a problem with implementations of type checkers: they are often inaccurate when announcing the apparent locations of mistakes in programs, tending to notice problems towards the end of the program even if the mistake occurs much earlier. This is a particular problem with programming languages with Hindley-Milner type systems such as used by Standard ML. A common technique for type inference is unification. Unifying types creates substitutions which are applied to types and type environments. The substitutions which have been applied to the type environment influence whether type errors are encountered in particular subexpressions of a program. This paper defines the operation of unifying substitutions and shows how type inference algorithms can be modified to use this operation to delay the ap...

The type systems of most typed functional programming languages are based on the Hindley-Milner type system. A practical problem with these type systems is that it is often hard to understand why a program is not type correct or a function does not have the intended type. We suggest that at the core of this problem is the difficulty of explaining why a given expression has a certain type. The type system is not defined compositionally. We propose to explain types using a variant of the Hindley-Milner type system that defines a compositional type explanation graph of principal typings. We describe how the programmer understands types by interactive navigation through the explanation graph. Furthermore, the explanation graph can be the foundation for algorithmic debugging of type errors, that is, semi-automatic localisation of the source of a type error without even having to understand the type inference steps. We implemented a prototype of a tool to explore the usefulness of the proposed methods.

. The error reports produced by compilers for languages with polymorphic type inference are often uninformative. Several attempts have been made to produce improved error reports. We dene a manifesto for good error reports and use it to evaluate both the traditional algorithms, and several improved algorithms, including two of our own devising. 1 Introduction Debugging type errors in programs written in polymorphic languages with type inference is hard [13, 7]. One reason is that much type information is implicit | inferred by the compiler. An error occurs in type inference when two uses of a program variable are found to be in conict, where each use occurs in some program text that we call a site. These concepts are best illustrated with an example. In Figure 1, inference proceeds left-to-right, initially assigning a type variable 'a to the function parameter x. From the rst use of x, sited at x 1, the algorithm infers that x is a function from integer to some unknown type, i....

Typically a type error is reported when unification fails, even though the programmer 's actual error may have occurred much earlier in the program. The and inference algorithms report the site where a type conflict is detected, but the error message is isolated information: it is not clear what the relationship is between the site where error is reported and the context in which the subexpression was typed. As a result, the error message may give little help to locate the source of the error. This report investigates better methods of explaining type conflicts. We aim to find a method that may be effective even when the user has little knowledge of type checking. The philosophy of our approach is to find sources of type errors by reporting which parts of the program conflict, rather than isolated error sites. We implement two new inference algorithms with this philosophy: the Unification of Assumption Environments ( AE) and the Incremented Error Inference ( ). 1

Tools and analyses that find bugs in software are becoming increasingly prevalent. However, even after the potential false alarms raised by such tools are dealt with, many real reported errors may go unfixed. In such cases the programmers have judged the benefit of fixing the bug to be less than the time cost of understanding and fixing it. The true utility of a bug-finding tool lies not in the number of bugs it finds but in the number of bugs it causes to be fixed. Analyses that find safety-policy violations typically give error reports as annotated backtraces or counterexamples. We propose that bug reports additionally contain a specially-constructed patch describing an example way in which the program could be modified to avoid the reported policy violation. Programmers viewing the analysis output can use such patches as guides, starting points, or as an additional way of understanding what went wrong. We present an algorithm for automatically constructing such patches given model-checking and policy information typically already produced by most such analyses. We are not aware of any previous automatic techniques for generating patches in response to safety policy violations. Our patches can suggest additional code not present in the original program, and can thus help to explain bugs related to missing program elements. In addition, our patches do not introduce any new violations of the given safety policy. To evaluate our method we performed a software engineering experiment, applying our algorithm to over 70 bug reports produced by two off-the-shelf bug-finding tools running on large Java programs. Bug reports also accompanied by patches were three times as likely to be addressed as standard bug reports. This work represents an early step toward developing new ways to report bugs and to make it easier for programmers to fix them. Even a minor increase in our ability to fix bugs would be a great increase for the quality of software.