Dominic Duggan and Frederick Bent. Explaining type inference. Science of Computer Programming, 27(1):37-83, 1996.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....error is reported in two di erent ways. There is some work aimed at providing a better understanding of type error and type inference. One approach is to provide better explanation of how the inference leads to a type error. We classify systems using this approach as explanation systems, e.g. [4, 15, 55]. Another approach is to provide a better error report, without necessarily explaining the inference that lead to the error. We classify systems using this approach as error reporting systems, e.g. 5, 14, 26, 32, 59] A third approach is to provide a mechanism for the programmer to probe the ....

....compiler entities such as generated type variables and elaborated core syntax. 2.4 Text based Hindley Milner type explanation systems Several type explanation systems have been based on tracing the behaviour of the W algorithm. Here, we consider the work of Soosaipillai[55] Duggan and Bent[15] and Beaven and Stansifer[4] and Ritri s proposal for an interactive type explanation system[49] 2.4.1 Soosaipillai s system Soosaipillai s system [55] explains type inference by menu traversal. The system uses a global list to record the subexpressions and their inferred types as a global ....

[Article contains additional citation context not shown here]

Dominic Duggan and Frederick Bent. Explaining type inference. Science of Computer Programming, 27:37-83, 1996. 164

....recover. Our proofs as programs design overcomes this by allowing greater flexibility because it keeps track of the dependencies within the same program and between different programs. Our proof design also allows us to locate errors in the program easily. 4] makes no consideration of datatypes. [6] gives an alternative approach to the problem of understanding type errors. He presents a modification of the unification algorithm used in Hindley Milner type inference which allows the decisions that led to a particular type being inferred to be recorded and fed back to the user. As I have not ....

D. Duggan and F. Bent. Explaining type inference. Science of Computer Programming, 27:37--83, 1996.

....Beaven and Stansifer [6] provide detailed explanations of the types of expressions in a (partially instantiated) typing derivation. In case, the typing derivation is incomplete due to a unification failure, they propose to investigate the two types that led to the failure. Duggan and Bent [12] criticize earlier attempts to locate the source of type errors. They propose to provide an explanation for the unification steps taken by the type inference algorithm prior to the error. The form of this explanation is a graph of subexpressions with their associated effect on the substitution ....

Dominic Duggan and Frederick Bent. Explaining type inference. Science of Computer Programming, 27(1):37--83, July 1996.

....In languages equipped with static typing and automatic type reconstruction, 66 CHAPTER 6. types need not be declared explicitly. This is the approach Kima has employed, but there has been a lot of work on explaining the source of type errors for strongly typed functional languages such as ML [37, 4, 9, 14, 38]. When a type error has been found, these systems explain why and how a particular type has been deduced. As far as we can see, they were implemented by extending the unification algorithm for type reconstruction. They recorded which symbol occurrence imposed which constraint in the type deduction ....

D. Duggan and F. Bent. Explaining Type Inference. Science of Computer Programming, 27(1):37--83, 1996.

....would be more helpful. We discuss the design of how the two differing type explain systems could be able to integrated with an existing system, HUGS. The emphasis in this work is how the error is presented to the user, as no algorithm to find the cause of an error seems available. Duggan and Bent [5] have said of such an algorithm we do not believe there is a general solution to this [problem] which scales up . Chapter 2 describes the fundamental algorithms of modern type checkers. Chapter 3 discusses previously published work related to this problem. Chapter 4 examines the two different ....

....of generic type variables. 10 Previous Work This chapter will review previously published work. Bruce McAdam s [11] modifications to the # algorithm is an attempt to make type debugging easier by changing the type checking algorithms. The work of Beaven and Stansifer [1] and Duggan and Bent[5] developed type explainer systems which attempt to analyse the type error and present it to the user in a clearer way. All three systems will be discussed in the following chapter. 3.1 McAdam s Unification of Substitutions McAdam identified a left to right bias in the # algorithm. If we ....

[Article contains additional citation context not shown here]

Dominic Duggan and Frederick Bent. Explaining type inference. Science of Computer Programming, 27:37--83, 1996.

....motivated work aimed at providing a better understanding of type error, often at the expense of additional computation. One approach is to provide better explanation of how the inference leads to a type error. The systems that use this approach are classified as error explanation systems, e.g. [1, 4, 11]. Another approach is to provide a better error report, without necessarily explaining the inference that lead to the error. Systems using this approach are classified as error reporting systems, e.g. 13, 5, 2, 8, 3] A third approach is to provide a mechanism for the programmer to probe the ....

....the programmer to probe the type of subexpressions [2] 4.1 Error Explanation Systems There have been several error explanation systems. For example, the system of Duggan and Bent uses a modified unification algorithm to record the reasons which led to a program variable having a particular type [4]. Figure 6 shows that Duggan and Bent s type inference explanation system explains the type of program variable n. Like the W algorithm, the system first assigns a type variable to type of n, then instantiates the type variable to the final type. The system of Beaven and Stansifer [1] explains ....

Dominic Duggan and Frederick Bent. Explaining type inference. Science of Computer Programming, 27:37-83, 1996.

....a similar system, except that it explains type errors rather than correctly typed programs. Again the programmer can ask why particular types were derived to get more information. The system has been implemented but not 19 integrated into any compiler. Dominic Duggan and Frederick Bent [DB96] devised a unification algorithm which collected explanations of why types were derived. The explanations take the form of a collection of locations in the program which were used to infer the type of some subexpression. This system has been added to a version of the Standard ML of New Jersey ....

....meet the requirements for correct type explanations in [Dug98] The graphs therefore generalise these other forms of information. Repairing Mistakes with Type Isomorphisms In the previous chapters of this thesis and in the work by others on type error messages [JW86, Wan86, BS93, Rit93a, BS95, DB96, Dug98, Yan97, Yan99, YMT00] the error messages and information produced relates to explaining where in a program the mistake may lie, and how the types which indicate the error were derived. This information is of help to the programmer in debugging the program, but is not of direct ....

[Article contains additional citation context not shown here]

Dominic Duggan and Frederick Bent. Explaining type inference. Science of Computer Programming, 27(1):37--83, 1996.

....as there may be several ways to correct the mistake, not all of which may be found by the system. If several are found then it is not possible to pick between them without human input. Other works on helping programmers debug type errors have not resulted in any techniques to transform syntax[Wan86, BS93, BS95, DB96, McA98, McA99, Yan99, YMT01, Chi01]. 1.2 THE THEORY BEHIND THIS SYSTEM Let s look at the example from the introduction. The problem is that the function map has type ( a b) a list b list which means that it takes a function and then a list as curried arguments but has been supplied with its arguments in ....

Dominic Duggan and Frederick Bent. Explaining type inference. Science of Computer Programming, 27(1):37--83, 1996.

....represents all of its types. Practical experience shows that the type checker catches many errors, from trivial oversights to sometimes even deep logical errors. But experience also shows that from a type error message it is often hard to deduce the actual cause of the error and understand it [1, 2, 3, 4, 9, 10, 17, 19, 20, 21, 22, 23, 24, 25, 26]. Consider the following tiny Haskell program [16] f xs ys = map toUpper) xs ys Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for prot or commercial advantage ....

....flow technique to the set of type equations to determine the most likely source of an error [21] Wand [22] modifies the unification algorithm used by W to keep track for every type variable which program fragment forces its instantiation. Beaven and Stansifer [1] and later Duggan and Bent [4] improve Wand s method. Choppella and Haynes present a related method [3] It might be possible to transfer some of these approaches to our type system to guide and reduce the number of questions in algorithmic debugging. Several people note the importance of an interactive tool. Soosaipillai ....

D. Duggan and F. Bent. Explaining type inference. Science of Computer Programming, 27(1):37--83, 1996.

....ones. Only when the integer constant 1 appears, the compiler realize that the expression x 1 is an integer sum and infers the type int to the variable x. Consequently, the inferred type for the above expression is int int. A good reference to the type inference algorithm of ML can be found in [DB96] 5 Subtyping Subtyping is a preorder (i.e. a reflexive and transitive relation) over types (strictly, over typeexpressions) such that the following substitution rule for expressions holds: If oe 0 : oe then expressions of type oe 0 can be used in any context where expressions of type oe ....

D. Duggan and F. Bent. Explaining type inference. Science of Computer Programming, 27:37--83, 1996.

....of the highlighting is made clear. 3. Have some sort of explanation facility. The user could click on a pink expression and get an explanation such as: has type int int int. Therefore, I would expect h: t to have type int. But it has type int list. Such type explanation systems do exist [DB96]. However, they tend to produce overly long explanations which can be very difficult to wade through. The advantage of C Y NTHIA is that we would only be applying the explanations to a small portion of the whole program. Hence, the explanations should be substantially shorter. I am currently ....

D. Duggan and F. Bent. Explaining type inference. Science of Computer Programming, 27:37--83, 1996.

....for example, with (fn x x 1) fn y if y then true else false) false ) it reports the whole expression as the error site, this large error source is not informative. There are several type inference explanation systems that explain how the inference process concludes a type error [2, 4, 9] . But there are some inherent problems in textual explanations: 1. Internal type variables which act as the bridge between instances, are actually the central point of the explanation, since they are the ones that get refined, but a programmer would not be concerned with those type variables. To ....

Dominic Duggan and Frederick Bent. Explaining type inference. Science of Computer Programming, 27:37--83, 1996.

....discipline from section 2. Unfortunately, the error messages for programs that do not type check are often confusing to beginners. Consider the program in figure 12. OCaml highlights the first pattern in the definition of helper , which is not where where the logical error occurs. While Duggan (Duggan Bent, 1996), Wand (Wand, 1986) and others have studied the problem of understanding type errors, their solutions do not apply to introductory programming environments, since they require the student to understand the type system. DrScheme s development suggests an alternative to these approaches. ....

Duggan, Dominic, & Bent, Frederick. 1996 (June). Explaining type inference. Science of Computer Programming.

....the steps of the inference to understand the full explanation of the required type. Duggan and Bent s system system explains type inference by analysing the instantiation of type variables during unification. A modified unification algorithm is used to record all instantiations of type variables [5]. The approach is similar to that used by Wand[20] to identify the sources of type errors. Other systems use similar unification algorithms to give type inference explanation, for example Rideau and Thery s programming environment[15] The system uses the essentially unchanged W algorithm to walk ....

Duggan, D. and Bent, F. Explaining type inference. Science of Computer Programming, 27:37--83, 1996. 21

....it is generally impossible to transform one well typed program into another without passing through intermediate, ill typed programs. Any type errors that do occur are highlighted to the user in a different colour. In general, it is very difficult to highlight the actual source of a type error [Duggan Bent 96] This is because the type inference algorithm breaks down when a type is derived that is inconsistent with a previously derived type. However, expressions early on may have a type derived that is correct in the local context but incorrect when the program is considered as a whole. This is not ....

D. Duggan and F. Bent. Explaining type inference. Science of Computer Programming, 27:37--83, 1996.

....motivated work aimed at providing a better understanding of type error, often at the expense of additional computation. One approach is to provide better explanation of how the inference leads to a type error. The systems that use this approach are classi ed as error explanation systems, e.g. [1, 4, 11]. Another approach is to provide a better error report, without necessarily explaining the inference that lead to the error. Systems using this approach are classi ed as error reporting systems, e.g. 13, 5, 2, 8, 3] A third approach is to provide a mechanism for the programmer to probe the ....

....the programmer to probe the type of subexpressions [2] 4.1 Error Explanation Systems There have been several error explanation systems. For example, the system of Duggan and Bend uses a modi ed uni cation algorithm to record the reasons which led to a program variable having a particular type [4]. The system of Beaven and Stansifer [1] explains how the inference reaches the two con icting types. Soosaipillai s system [11] explains the type inference by menu traversal. Compared to our manifesto, type error explanation systems can be made comprehensive, precise, and correct. However they ....

[Article contains additional citation context not shown here]

Dominic Duggan and Frederick Bent. Explaining type inference. Science of Computer Programming, 27:37-83, 1996.

....for generating textual explanations of the types inferred before an error was detected. It is suggested 9 that in the future it may be possible to create a system which both explains deductions and suggests where the error may be found, that is part of the aim of this project. Duggan and Bent, [DB96], explain type inference by analysing the changes made to graphs (representing substitutions) during unification. The technique used here is to modify unification to record all the instantiations of type variables made. It is claimed that the approach mimics how people understand type inference. ....

....in Standard ML. The results will, however, be relevant to other programming languages with more complex type systems because of their basis in Hindley Milner type systems and unification based algorithms. Results may also be relevant to logic programming (as Duggan and Bent suggest of their work [DB96]) 11 Observation 7 The problem of type checking correctly typed programs is well understood, this project is concerned with incorrectly typed programs. Input to software produced as part of this project will be restricted to programs known, or thought, to contain a problem. Principle 7 ....

[Article contains additional citation context not shown here]

Dominic Duggan and Frederick Bent. Explaining type inference. Science of Computer Programming, (27):37--83, 1996.

....type inference. The reported location of the error may be far away from the code that causes the error, and the error message itself may confuse those who don t understand the underlying unification algorithm. Elaborate methods have been proposed to help users understand errors in type inference [21, 22, 23]. This particular collection of combinators arose as part of an effort to improve the error reporting ability of a compiler designed to halt after a single error. The ERROR and OK combinators provided the basic ability of adjoining an error value to any type. The next additions were emap, which ....

Dominic Duggan and Frederick Bent. Explaining type inference. Science of Computer Programming, 7(1), June 1996.

....bool , the second has function type int int. Even worse, when the W algorithm succeeds at every subexpression and fails at the top application expression, it reports the whole expression as the error site, for example in Figure 2. There are several type inference explanation system such as [4] [6] and [7] There are some inherent problems in textual explanations: 1. Type variables are the central point of the explanation since they are the ones that get re ned. To understand the explanations, it is necessary to remember from which program variable the type variable fn arg ) if arg then ....

....applications; then switch to M app , which checks each subexpression in INC app . endcase Figure 12: The incremental type error inference INC app for application. 4 Discussion We now discuss di erent type error explanation methods. Type error explanation systems: In Duggan s explanation system [6], internal type variables which act as bridge between instances, are actually the central point of the explanation, since they are the ones that get re ned, but a programmer would not be concerned with those type variables. Beaven s Explaining Type Errors in Polymorphic Languages [4] gives a long ....

Dominic Duggan and Frederick Bent. Explaining type inference. Science of Computer Programming, (27):37-83, 1996.

....value is. For example the numeral 1 is typically given type int (integer) An arithmetic expression would also be given the type int (or possibly real if it involves real numbers) In many languages, complex types are built from simpler sub types and type constructors, e.g. the list of numbers [1, 2, 3] would be given type int list built from the type int and the constructor list. The type of a function or procedure is built using a constructor and the types of its domain and range, e.g. the trigonometry sin function would have type real real. Groups of values, know as tuples, have the ....

....popular PolyML compiler advises the user of type errors The quality of this information varies between compilers and the programmer must learn to interpret it correctly to aid debugging. Other attempts to give more type information to the user have centred around explaining wrongly typed programs ([3]) 4.2 What more do BigTypes offer In contrast, BigTypes offer the user additional information about correctly typed programs. This is useful as programmers often assume that once a program is correctly typed, it will perform the task required correctly. BigTypes will aid the debugging by ....

[Article contains additional citation context not shown here]

Dominic Duggan and Frederick Bent. Explaining type inference. Science of Computer Programming, (27):37--83, 1996.

No context found.

Dominic Duggan and Frederick Bent. Explaining type inference. Science of Computer Programming, 27(1):37-83, 1996.

No context found.

D. Duggan and F. Bent. Explaining type inference. Science of Computer Programming, 27(1):37--83, July 1996.

No context found.

D. Duggan and F. Bent. Explaining type inference. Science of Computer Programming, 27(1):37--83, July 1996.

No context found.

Dominic Duggan and Frederick Bent. Explaining type inference. Science of Computer Programming, (27):37--83, 1996.

No context found.

Dominic Duggan and Frederick Bent. Explaining type inference. Science of Computer Programming, 7(1), June 1996.

First 50 documents

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC