28,792 research outputs found
Soft Contract Verification
Behavioral software contracts are a widely used mechanism for governing the
flow of values between components. However, run-time monitoring and enforcement
of contracts imposes significant overhead and delays discovery of faulty
components to run-time.
To overcome these issues, we present soft contract verification, which aims
to statically prove either complete or partial contract correctness of
components, written in an untyped, higher-order language with first-class
contracts. Our approach uses higher-order symbolic execution, leveraging
contracts as a source of symbolic values including unknown behavioral values,
and employs an updatable heap of contract invariants to reason about
flow-sensitive facts. We prove the symbolic execution soundly approximates the
dynamic semantics and that verified programs can't be blamed.
The approach is able to analyze first-class contracts, recursive data
structures, unknown functions, and control-flow-sensitive refinements of
values, which are all idiomatic in dynamic languages. It makes effective use of
an off-the-shelf solver to decide problems without heavy encodings. The
approach is competitive with a wide range of existing tools---including type
systems, flow analyzers, and model checkers---on their own benchmarks.Comment: ICFP '14, September 1-6, 2014, Gothenburg, Swede
Dynamically typed languages
Dynamically typed languages such as Python and Ruby have experienced a rapid grown in popularity in recent times. However, there is much confusion as to what makes these languages interesting relative to statically typed languages, and little knowledge of their rich history. In this chapter I explore the general topic of dynamically typed languages, how they differ from statically typed languages, their history, and their defining features
Trust, but Verify: Two-Phase Typing for Dynamic Languages
A key challenge when statically typing so-called dynamic languages is the
ubiquity of value-based overloading, where a given function can dynamically
reflect upon and behave according to the types of its arguments. Thus, to
establish basic types, the analysis must reason precisely about values, but in
the presence of higher-order functions and polymorphism, this reasoning itself
can require basic types. In this paper we address this chicken-and-egg problem
by introducing the framework of two-phased typing. The first "trust" phase
performs classical, i.e. flow-, path- and value-insensitive type checking to
assign basic types to various program expressions. When the check inevitably
runs into "errors" due to value-insensitivity, it wraps problematic expressions
with DEAD-casts, which explicate the trust obligations that must be discharged
by the second phase. The second phase uses refinement typing, a flow- and
path-sensitive analysis, that decorates the first phase's types with logical
predicates to track value relationships and thereby verify the casts and
establish other correctness properties for dynamically typed languages
Gradual Liquid Type Inference
Liquid typing provides a decidable refinement inference mechanism that is
convenient but subject to two major issues: (1) inference is global and
requires top-level annotations, making it unsuitable for inference of modular
code components and prohibiting its applicability to library code, and (2)
inference failure results in obscure error messages. These difficulties
seriously hamper the migration of existing code to use refinements. This paper
shows that gradual liquid type inference---a novel combination of liquid
inference and gradual refinement types---addresses both issues. Gradual
refinement types, which support imprecise predicates that are optimistically
interpreted, can be used in argument positions to constrain liquid inference so
that the global inference process e effectively infers modular specifications
usable for library components. Dually, when gradual refinements appear as the
result of inference, they signal an inconsistency in the use of static
refinements. Because liquid refinements are drawn from a nite set of
predicates, in gradual liquid type inference we can enumerate the safe
concretizations of each imprecise refinement, i.e. the static refinements that
justify why a program is gradually well-typed. This enumeration is useful for
static liquid type error explanation, since the safe concretizations exhibit
all the potential inconsistencies that lead to static type errors. We develop
the theory of gradual liquid type inference and explore its pragmatics in the
setting of Liquid Haskell.Comment: To appear at OOPSLA 201
Logic programming in the context of multiparadigm programming: the Oz experience
Oz is a multiparadigm language that supports logic programming as one of its
major paradigms. A multiparadigm language is designed to support different
programming paradigms (logic, functional, constraint, object-oriented,
sequential, concurrent, etc.) with equal ease. This article has two goals: to
give a tutorial of logic programming in Oz and to show how logic programming
fits naturally into the wider context of multiparadigm programming. Our
experience shows that there are two classes of problems, which we call
algorithmic and search problems, for which logic programming can help formulate
practical solutions. Algorithmic problems have known efficient algorithms.
Search problems do not have known efficient algorithms but can be solved with
search. The Oz support for logic programming targets these two problem classes
specifically, using the concepts needed for each. This is in contrast to the
Prolog approach, which targets both classes with one set of concepts, which
results in less than optimal support for each class. To explain the essential
difference between algorithmic and search programs, we define the Oz execution
model. This model subsumes both concurrent logic programming
(committed-choice-style) and search-based logic programming (Prolog-style).
Instead of Horn clause syntax, Oz has a simple, fully compositional,
higher-order syntax that accommodates the abilities of the language. We
conclude with lessons learned from this work, a brief history of Oz, and many
entry points into the Oz literature.Comment: 48 pages, to appear in the journal "Theory and Practice of Logic
Programming
- …