Results 1  10
of
42
Gradual Typing for Functional Languages
 IN SCHEME AND FUNCTIONAL PROGRAMMING WORKSHOP
, 2006
"... Static and dynamic type systems have wellknown strengths and weaknesses, and each is better suited for different programming tasks. There have been many efforts to integrate static and dynamic typing and thereby combine the benefits of both typing disciplines in the same language. The flexibility o ..."
Abstract

Cited by 81 (13 self)
 Add to MetaCart
Static and dynamic type systems have wellknown strengths and weaknesses, and each is better suited for different programming tasks. There have been many efforts to integrate static and dynamic typing and thereby combine the benefits of both typing disciplines in the same language. The flexibility of static typing can be improved by adding a type Dynamic and a typecase form. The safety and performance of dynamic typing can be improved by adding optional type annotations or by performing type inference (as in soft typing). However, there has been little formal work on type systems that allow a programmercontrolled migration between dynamic and static typing. Thatte proposed QuasiStatic Typing, but it does not statically catch all type errors in completely annotated programs. Anderson and Drossopoulou defined a nominal type system for an objectoriented language with optional type annotations. However, developing a sound, gradual type system for functional languages with structural types is an open problem. In this paper
Gradual typing for objects
 In ECOOP 2007, volume 4609 of LCNS
, 2007
"... Abstract. Static and dynamic type systems have wellknown strengths and weaknesses, and each is better suited for different programming tasks. In previous work we developed a gradual type system for a functional calculus named λ?→. Gradual typing provides the benefits of both static and dynamic che ..."
Abstract

Cited by 69 (11 self)
 Add to MetaCart
(Show Context)
Abstract. Static and dynamic type systems have wellknown strengths and weaknesses, and each is better suited for different programming tasks. In previous work we developed a gradual type system for a functional calculus named λ?→. Gradual typing provides the benefits of both static and dynamic checking in a single language by allowing the programmer to control whether a portion of the program is type checked at compiletime or runtime, and allows for convenient migration between the two by adding or removing type annotations on variables. Gradual typing introduces a statically unknown type, written?, and replaces the use of type equality in the type system with a new relation called type consistency which checks for equality in the parts where both types are statically known. Objectoriented scripting languages such as JavaScript and Perl 6 are preparing to add static checking. In support of that work, this paper develops Ob?<:, a gradual type system for objectbased languages, extending the Ob<: calculus of Abadi and Cardelli. Our primary contribution is to show that type consistency and subtyping are orthogonal and can be combined in a principled fashion. We also develop a smallstep semantics for the calculus, provide a machinechecked proof of type safety, and improve the space efficiency of higherorder casts. 1
Verifying safety properties with the TLA+ proof system
 In Jürgen Giesl and Reiner Hähnle, editors, Intl. Joint Conf. Automated Reasoning (IJCAR 2010), volume 6173 of Lecture Notes in Computer Science
, 2010
"... TLAPS, the TLA+ proof system, is a platform for the development and mechanical verification of TLA+ proofs. The TLA+ proof language is declarative, and understanding proofs requires little background beyond elementary mathematics. The language supports hierarchical and nonlinear proof construction ..."
Abstract

Cited by 18 (8 self)
 Add to MetaCart
(Show Context)
TLAPS, the TLA+ proof system, is a platform for the development and mechanical verification of TLA+ proofs. The TLA+ proof language is declarative, and understanding proofs requires little background beyond elementary mathematics. The language supports hierarchical and nonlinear proof construction and verification, and it is independent of any verification tool or strategy. Proofs are written in the same language as specifications; engineers do not have to translate their highlevel designs into the language of a particular verification tool. A proof manager interprets a TLA+ proof as a collection of proof obligations to be verified, which it sends to backend verifiers that include theorem provers, proof assistants, SMT solvers, and decision procedures. The first public release of TLAPS is available from [1], distributed with a BSDlike license. It handles almost all the nontemporal part of TLA+ as well as the temporal reasoning needed to prove standard safety properties, in particular invariance and step simulation, but not liveness properties. Intuitively, a safety property asserts what is permitted to happen; a liveness property asserts what must happen; for a more formal overview, see [3, 10]. 2
Building formal method tools in the Isabelle/Isar framework
 THEOREM PROVING IN HIGHER ORDER LOGICS (TPHOLS 2007), LNCS
, 2007
"... We present the generic system framework of Isabelle/Isar underlying recent versions of Isabelle. Among other things, Isar provides an infrastructure for Isabelle plugins, comprising extensible state components and extensible syntax that can be bound to tactical ML programs. Thus the Isabelle/Isar ..."
Abstract

Cited by 12 (6 self)
 Add to MetaCart
(Show Context)
We present the generic system framework of Isabelle/Isar underlying recent versions of Isabelle. Among other things, Isar provides an infrastructure for Isabelle plugins, comprising extensible state components and extensible syntax that can be bound to tactical ML programs. Thus the Isabelle/Isar architecture may be understood as an extension and refinement of the traditional “LCF approach”, with explicit infrastructure for building derivative systems. To demonstrate the technical potential of the framework, we apply it to a concrete formal methods tool: the HOLZ 3.0 environment, which is geared towards the analysis of Z specifications and formal proof of forwardrefinements.
Mizar Light for HOL Light
 Theorem Proving in Higher Order Logics: TPHOLs 2001, LNCS 2152
, 2001
"... There are two dierent approaches to formalizing proofs in a computer: the procedural approach (which is the one of the HOL system) and the declarative approach (which is the one of the Mizar system). ..."
Abstract

Cited by 11 (3 self)
 Add to MetaCart
(Show Context)
There are two dierent approaches to formalizing proofs in a computer: the procedural approach (which is the one of the HOL system) and the declarative approach (which is the one of the Mizar system).
A Comparison of the Mathematical Proof Languages Mizar and Isar
 Journal of Automated Reasoning
, 2002
"... The mathematical proof checker Mizar by Andrzej Trybulec uses a proof input language that is much more readable than the input languages of most other proof assistants. This system also di#ers in many other respects from most current systems. John Harrison has shown that one can have a Mizar mode on ..."
Abstract

Cited by 10 (3 self)
 Add to MetaCart
The mathematical proof checker Mizar by Andrzej Trybulec uses a proof input language that is much more readable than the input languages of most other proof assistants. This system also di#ers in many other respects from most current systems. John Harrison has shown that one can have a Mizar mode on top of a tactical prover, allowing one to combine a mathematical proof language with other styles of proof checking. Currently the only fully developed Mizar mode in this style is the Isar proof language for the Isabelle theorem prover. In fact the Isar language has become the o#cial input language to the Isabelle system, even though many users still use its lowlevel tactical part only.
A Comparison of Mizar and Isar
 J. Automated Reasoning
, 2002
"... Abstract. The mathematical proof checker Mizar by Andrzej Trybulec uses a proof input language that is much more readable than the input languages of most other proof assistants. This system also differs in many other respects from most current systems. John Harrison has shown that one can have a Mi ..."
Abstract

Cited by 8 (0 self)
 Add to MetaCart
Abstract. The mathematical proof checker Mizar by Andrzej Trybulec uses a proof input language that is much more readable than the input languages of most other proof assistants. This system also differs in many other respects from most current systems. John Harrison has shown that one can have a Mizar mode on top of a tactical prover, allowing one to combine a mathematical proof language with other styles of proof checking. Currently the only fully developed Mizar mode in this style is the Isar proof language for the Isabelle theorem prover. In fact the Isar language has become the official input language to the Isabelle system, even though many users still use its lowlevel tactical part only. In this paper we compare Mizar and Isar. A small example, Euclid’s proof of the existence of infinitely many primes, is shown in both systems. We also include slightly higherlevel views of formal proof sketches. Moreover a list of differences between Mizar and Isar is presented, highlighting the strengths of both systems from the perspective of endusers. Finally, we point out some key differences of the
A semantic analysis of C++ templates
 In ECOOP ’06: Proceedings of the 20th European Conference on ObjectOriented Programming, ECOOP’06
, 2006
"... Abstract. Templates are a powerful but poorly understood feature of the C++ language. Their syntax resembles the parameterized classes of other languages (e.g., of Java). But because C++ supports template specialization, their semantics is quite different from that of parameterized classes. Templat ..."
Abstract

Cited by 6 (0 self)
 Add to MetaCart
(Show Context)
Abstract. Templates are a powerful but poorly understood feature of the C++ language. Their syntax resembles the parameterized classes of other languages (e.g., of Java). But because C++ supports template specialization, their semantics is quite different from that of parameterized classes. Template specialization provides a Turingcomplete sublanguage within C++ that executes at compiletime. Programmers put this power to many uses. For example, templates are a popular tool for writing program generators. The C++ Standard defines the semantics of templates using natural language, so it is prone to misinterpretation. The metatheoretic properties of C++ templates have not been studied, so the semantics of templates has not been systematically checked for errors. In this paper we present the first formal account of C++ templates including some of the more complex aspects, such as template partial specialization. We validate our semantics by proving type safety and verify the proof with the Isabelle proof assistant. Our formalization reveals two interesting issues in the C++ Standard: the first is a problem with member instantiation and the second concerns the generation of unnecessary template specializations. 1
Miscellaneous Isabelle/Isar examples for higherorder logic. Part of the Isabelle distribution, http://isabelle.in.tum.de/library/ HOL/Isar examples/document.pdf
, 2001
"... Isar offers a highlevel proof (and theory) language for Isabelle. We give various examples of Isabelle/Isar proof developments, ranging from simple demonstrations of certain language features to a bit more advanced applications. The “real ” applications of Isabelle/Isar are found elsewhere. Content ..."
Abstract

Cited by 5 (2 self)
 Add to MetaCart
Isar offers a highlevel proof (and theory) language for Isabelle. We give various examples of Isabelle/Isar proof developments, ranging from simple demonstrations of certain language features to a bit more advanced applications. The “real ” applications of Isabelle/Isar are found elsewhere. Contents 1 Basic logical reasoning 3 1.1 Pure backward reasoning.................... 3 1.2 Variations of backward vs. forward reasoning......... 4 1.3 A few examples from “Introduction to Isabelle ”........ 5