Dependent Types for Program Understanding

Komondoor, Raghavan; Ramalingam, G.; Chandra, Satish; Field, John

doi:10.1007/978-3-540-31980-1_11

Cited by 22 publications

(19 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…x). Third, the treatment of combinations of tests relies on an ad-hoc collection of rules.1 Komondoor et al [2005] independently coined the term "occurrence typing" in the context of providing an advanced type system for COBOL.In this paper, we present a new and simple framework for occurrence typing that eliminates all three problems via an increase in expressive power. The key innovation is to turn control flow predicates into formulas in propositional logic for reasoning about the types of variables.…”

mentioning

confidence: 99%

Logical types for untyped languages

Tobin-Hochstadt

Felleisen

2010

SIGPLAN Not.

View full text Add to dashboard Cite

Programmers reason about their programs using a wide variety of formal and informal methods. Programmers in untyped languages such as Scheme or Erlang are able to use any such method to reason about the type behavior of their programs. Our type system for Scheme accommodates common reasoning methods by assigning variable occurrences a subtype of their declared type based on the predicates prior to the occurrence, a discipline dubbed occurrence typing. It thus enables programmers to enrich existing Scheme code with types, while requiring few changes to the code itself.Three years of practical experience has revealed serious shortcomings of our type system. In particular, it relied on a system of ad-hoc rules to relate combinations of predicates, it could not reason about subcomponents of data structures, and it could not follow sophisticated reasoning about the relationship among predicate tests, all of which are used in existing code.In this paper, we reformulate occurrence typing to eliminate these shortcomings. The new formulation derives propositional logic formulas that hold when an expression evaluates to true or false, respectively. A simple proof system is then used to determine types of variable occurrences from these propositions. Our implementation of this revised occurrence type system thus copes with many more untyped programming idioms than the original system. Reasoning about Untyped LanguagesDeveloping programs in a typed language helps programmers avoid mistakes. It also forces them to provide some documentation, and it establishes some protective abstraction barriers. As such, the type system imposes a discipline on the programming process.Nevertheless, numerous programmers continue to choose untyped scripting languages for their work, including many who work in a functional style. When someone eventually decides that explicitly stated type information reduces maintenance cost, they face a dilemma. To address this situation, we need to develop typed sister languages for untyped languages. With those, programmers can enrich existing programs with type declarations as needed while maintaining smooth interoperability.A type system for an existing untyped language must accommodate the existing programming idioms in order to keep the cost of * This research was partially supported by grants from the US NSF and a donation from the Mozilla Foundation.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 profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. ICFP'10, September 27-29, 2010, Baltimore, Maryland, USA. Copyright c 2010 ACM 978-1-60558-794-3/10/09. . . $10.00 type enrichment low. Otherwise, type enrichment requires changes to code, which may introduce new mistakes. Put positively, the id...

show abstract

mentioning

confidence: 99%

Logical types for untyped languages

Tobin-Hochstadt

Felleisen

2010

SIGPLAN Not.

View full text Add to dashboard Cite

show abstract

“…In [11] researchers present an analysis of Cobol programs that recovers information corresponding to tagged unions. The work on the C programming language [9,2] deals with a language that allows subtle pointer and address arithmetic manipulations, but already contains significant static type information.…”

Section: Related Workmentioning

confidence: 99%

Runtime Instrumentation for Precise Flow-Sensitive Type Analysis

Kneuss

Suter

Kunčak

2010

Runtime Verification

View full text Add to dashboard Cite

Abstract. We describe a combination of runtime information and static analysis for checking properties of complex and configurable systems. The basic idea of our approach is to 1) let the program execute and thereby read the important dynamic configuration data, then 2) invoke static analysis from this runtime state to detect possible errors that can happen in the continued execution. This approach improves analysis precision, particularly with respect to types of global variables and nested data structures. It also enables the resolution of modules that are loaded based on dynamically computed information. We describe an implementation of this approach in a tool that statically computes possible types of variables in PHP applications, including detailed types of nested maps (arrays). PHP is a dynamically typed language; PHP programs extensively use nested value maps, as well as 'include' directives whose arguments are dynamically computed file names. We have applied our analysis tool to over 50'000 lines of PHP code, including the popular DokuWiki software, which has a plug-in architecture. The analysis identified 200 problems in the code and in the type hints of the original source code base. Some of these problems can cause exploits, infinite loops, and crashes. Our experiments show that dynamic information simplifies the development of the analysis and decreases the number of false alarms compared to a purely static analysis approach.

show abstract

“…However, because Cobol has no notion of user-defined types, information about such classes is not evident from examining the data declarations in the program. In previous work [7,12], we have presented algorithms for inferring a logical data model from a Cobol application. A logical data model links program variables to classes (logical types), thus identifying variables of the same class; it also contains inheritance and containment relationships between the classes.…”

Section: Events Related To Logical Typesmentioning

confidence: 99%