Results 1  10
of
19
Practical RefinementType Checking
, 1997
"... Refinement types allow many more properties of programs to be expressed and statically checked than conventional type systems. We present a practical algorithm for refinementtype checking in a calculus enriched with refinementtype annotations. We prove that our basic algorithm is sound and comple ..."
Abstract

Cited by 38 (1 self)
 Add to MetaCart
Refinement types allow many more properties of programs to be expressed and statically checked than conventional type systems. We present a practical algorithm for refinementtype checking in a calculus enriched with refinementtype annotations. We prove that our basic algorithm is sound and complete, and show that every term which has a refinement type can be annotated as required by our algorithm. Our positive experience with an implementation of an extension of this algorithm to the full core language of Standard ML demonstrates that refinement types can be a practical program development tool in a realistic programming language. The required refinement type definitions and annotations are not much of a burden and serve as formal, machinechecked explanations of code invariants which otherwise would remain implicit. 1 Introduction The advantages of staticallytyped programming languages are well known, and have been described many times (e.g. see [Car97]). However, conventional ty...
Practical Implementation of a Dependently Typed Functional Programming Language
, 2005
"... Language ..."
Smallcheck and lazy smallcheck: automatic exhaustive testing for small values
 In Haskell ’08: Proceedings of the first ACM SIGPLAN symposium on Haskell
, 2008
"... This paper describes two Haskell libraries for propertybased testing. Following the lead of QuickCheck (Claessen and Hughes 2000), these testing libraries SmallCheck and Lazy SmallCheck also use typebased generators to obtain testsets of finite values for which properties are checked, and report ..."
Abstract

Cited by 26 (0 self)
 Add to MetaCart
This paper describes two Haskell libraries for propertybased testing. Following the lead of QuickCheck (Claessen and Hughes 2000), these testing libraries SmallCheck and Lazy SmallCheck also use typebased generators to obtain testsets of finite values for which properties are checked, and report any counterexamples found. But instead of using a sample of randomly generated values they test properties for all values up to some limiting depth, progressively increasing this limit. The paper explains the design and implementation of both libraries and evaluates them in comparison with each other and with QuickCheck. Categories and Subject Descriptors D.1.1 [Applicative (Functional)
Fast Mergeable Integer Maps
 In Workshop on ML
, 1998
"... Finite maps are ubiquitous in many applications, but perhaps nowhere more so than in compilers and other language processors. In these applications, three operations on finite maps dominate all others: looking up the value associated with a key, inserting a new binding, and merging two finite maps. ..."
Abstract

Cited by 25 (1 self)
 Add to MetaCart
Finite maps are ubiquitous in many applications, but perhaps nowhere more so than in compilers and other language processors. In these applications, three operations on finite maps dominate all others: looking up the value associated with a key, inserting a new binding, and merging two finite maps. Most implementations of finite maps in functional languages are based on balanced binary search trees, which perform well on the first two, but poorly on the third. We describe an implementation of finite maps with integer keys that performs well in practice on all three operations. This data structure is not new  indeed, it is thirty years old this year  but it deserves to be more widely known.
StaticallyDirected Dynamic Automated Test Generation
, 2011
"... We present a new technique for exploiting static analysis to guide dynamic automated test generation for binary programs, prioritizing the paths to be explored. Our technique is a threestage process, which alternates dynamic and static analysis. In the first stage, we run dynamic analysis with a sm ..."
Abstract

Cited by 12 (3 self)
 Add to MetaCart
We present a new technique for exploiting static analysis to guide dynamic automated test generation for binary programs, prioritizing the paths to be explored. Our technique is a threestage process, which alternates dynamic and static analysis. In the first stage, we run dynamic analysis with a small number of seed tests to resolve indirect jumps in the binary code and build a visibly pushdown automaton (VPA) reflecting the global controlflow of the program. Further, we augment the computed VPA with statically computable jumps not executed by the seed tests. In the second stage, we apply static analysis to the inferred automaton to find potential vulnerabilities, i.e., targets for the dynamic analysis. In the third stage, we use the results of the prior phases to assign weights to VPA edges. Our symbolicexecution based automated test generation tool then uses the weighted shortestpath lengths in the VPA to direct its exploration to the target potential vulnerabilities. Preliminary experiments on a suite of benchmarks extracted from real applications show that static analysis allows exploration to reach vulnerabilities it otherwise would not, and the generated test inputs prove that the static warnings indicate true positives.
Fixed points of type constructors and primitive recursion
 Computer Science Logic, 18th International Workshop, CSL 2004, 13th Annual Conference of the EACSL, Karpacz, Poland, September 2024, 2004, Proceedings, volume 3210 of Lecture Notes in Computer Science
, 2004
"... Our contribution to CSL 04 [AM04] contains a little error, which is easily corrected by 2 elementary editing steps (replacing one character and deleting another). Definition of wellformed contexts (fifth page). Typing contexts should, in contrast to kinding contexts, only contain type variable decla ..."
Abstract

Cited by 7 (3 self)
 Add to MetaCart
Our contribution to CSL 04 [AM04] contains a little error, which is easily corrected by 2 elementary editing steps (replacing one character and deleting another). Definition of wellformed contexts (fifth page). Typing contexts should, in contrast to kinding contexts, only contain type variable declarations without variance information. Hence, the second rule is too liberal; we must insist on p = ◦. The corrected set of rules is then: ⋄ cxt ∆ cxt ∆, X ◦κ cxt ∆ cxt ∆ ⊢ A: ∗ ∆, x:A cxt Definition of welltyped terms (immediately following). Since wellformed typing contexts ∆ contain no variance information, hence ◦ ∆ = ∆, we might drop the “◦ ” in the instantiation rule (fifth rule). The new set of rules is consequently, (x:A) ∈ ∆ ∆ cxt ∆ ⊢ x: A ∆, X ◦κ ⊢ t: A ∆ ⊢ t: ∀X κ. A ∆, x:A ⊢ t: B ∆ ⊢ λx.t: A → B ∆ ⊢ t: ∀X κ. A ∆ ⊢ F: κ
An Overview of the Leon Verification System Verification by Translation to Recursive Functions
"... We present the Leon verification system for a subset of the Scala programming language. Along with several functional features of Scala, Leon supports imperative constructs such as mutations and loops, using a translation into recursive functional form. Both properties and programs in Leon are expre ..."
Abstract

Cited by 2 (2 self)
 Add to MetaCart
We present the Leon verification system for a subset of the Scala programming language. Along with several functional features of Scala, Leon supports imperative constructs such as mutations and loops, using a translation into recursive functional form. Both properties and programs in Leon are expressed in terms of userdefined functions. We discuss several techniques that led to an efficient semidecision procedure for firstorder constraints with recursive functions, which is the core solving engine of Leon. We describe a generational unrolling strategy for recursive templates that yields smaller satisfiable formulas and ensures completeness for counterexamples. We illustrate the current capabilities of Leon on a set of examples, such as data structure implementations; we show that Leon successfully finds bugs or proves completeness of pattern matching as well as validity of function postconditions.
Benchmarking Purely Functional Data Structures
 Journal of Functional Programming
, 1999
"... When someone designs a new data structure, they want to know how well it performs. Previously, the only way to do this involves finding, coding and testing some applications to act as benchmarks. This can be tedious and timeconsuming. Worse, how a benchmark uses a data structure may considerably af ..."
Abstract

Cited by 2 (0 self)
 Add to MetaCart
When someone designs a new data structure, they want to know how well it performs. Previously, the only way to do this involves finding, coding and testing some applications to act as benchmarks. This can be tedious and timeconsuming. Worse, how a benchmark uses a data structure may considerably affect the efficiency of the data structure. Thus, the choice of benchmarks may bias the results. For these reasons, new data structures developed for functional languages often pay little attention to empirical performance. We solve these problems by developing a benchmarking tool, Auburn, that can generate benchmarks across a fair distribution of uses. We precisely define "the use of a data structure", upon which we build the core algorithms of Auburn: how to generate a benchmark from a description of use, and how to extract a description of use from an application. We consider how best to use these algorithms to benchmark competing data structures. Finally, we test Auburn by benchmarking ...