Results 1 -
8 of
8
A principled approach to operating system construction in Haskell
- In ICFP ’05: Proceedings of the Tenth ACM SIGPLAN International Conference on Functional Programming
, 2005
"... We describe a monadic interface to low-level hardware features that is a suitable basis for building operating systems in Haskell. The interface includes primitives for controlling memory management hardware, user-mode process execution, and low-level device I/O. The interface enforces memory safety ..."
Abstract
-
Cited by 34 (2 self)
- Add to MetaCart
We describe a monadic interface to low-level hardware features that is a suitable basis for building operating systems in Haskell. The interface includes primitives for controlling memory management hardware, user-mode process execution, and low-level device I/O. The interface enforces memory safety in nearly all circumstances. Its behavior is specified in part by formal assertions written in a programming logic called P-Logic. The interface has been implemented on bare IA32 hardware using the Glasgow Haskell Compiler (GHC) runtime system. We show how a variety of simple O/S kernels can be constructed on top of the interface, including a simple separation kernel and a demonstration system in which the kernel, window system, and all device drivers are written in Haskell.
Static Contract Checking for Haskell
- In Proceedings of the 36 th Annual ACM Symposium on the Principles of Programming Languages
, 2009
"... Program errors are hard to detect and are costly both to programmers who spend significant efforts in debugging, and for systems that are guarded by runtime checks. Static verification techniques have been applied to imperative and object-oriented languages, like Java and C#, but few have been appli ..."
Abstract
-
Cited by 12 (1 self)
- Add to MetaCart
Program errors are hard to detect and are costly both to programmers who spend significant efforts in debugging, and for systems that are guarded by runtime checks. Static verification techniques have been applied to imperative and object-oriented languages, like Java and C#, but few have been applied to a higher-order lazy functional language, like Haskell. In this paper, we describe a sound and automatic static verification framework for Haskell, that is based on contracts and symbolic execution. Our approach is modular and gives precise blame assignments at compile-time in the presence of higher-order functions and laziness. D.3 [Software]: Program-
A Hoare Logic for Call-by-Value Functional Programs
"... Abstract. We present a Hoare logic for a call-by-value programming language equipped with recursive, higher-order functions, algebraic data types, and a polymorphic type system in the style of Hindley and Milner. It is the theoretical basis for a tool that extracts proof obligations out of programs ..."
Abstract
-
Cited by 11 (1 self)
- Add to MetaCart
Abstract. We present a Hoare logic for a call-by-value programming language equipped with recursive, higher-order functions, algebraic data types, and a polymorphic type system in the style of Hindley and Milner. It is the theoretical basis for a tool that extracts proof obligations out of programs annotated with logical assertions. These proof obligations, expressed in a typed, higher-order logic, are discharged using off-theshelf automated or interactive theorem provers. Although the technical apparatus that we exploit is by now standard, its application to callby-value functional programming languages appears to be new, and (we claim) deserves attention. As a sample application, we check the partial correctness of a balanced binary search tree implementation. 1
An overview of the programatica toolset
- High Confidence Software and Systems Conference, HCSS04, http://www.cse.ogi.edu/~hallgren/ Programatica/HCSS04
, 2004
"... With ever increasing use of computers in safety and security critical applications, the need for trustworthy computer systems has never been greater. But how can such trust be established? For example, how can we be sure that our computer systems will not destroy or corrupt valuable data, compromise ..."
Abstract
-
Cited by 6 (0 self)
- Add to MetaCart
With ever increasing use of computers in safety and security critical applications, the need for trustworthy computer systems has never been greater. But how can such trust be established? For example, how can we be sure that our computer systems will not destroy or corrupt valuable data, compromise privacy, or trigger
Position: Lightweight Static Resources: Sexy types for embedded and systems programming
- In TFP ’07, the 8 th Symposium on Trends in Functional Programming
, 2007
"... It is an established trend to develop low-level code—embedded software, device drivers, and operating systems—using high-level languages, especially functional languages with advanced facilities to abstract and generate code. To be reliable and secure, low-level code must correctly manage space, tim ..."
Abstract
-
Cited by 5 (3 self)
- Add to MetaCart
It is an established trend to develop low-level code—embedded software, device drivers, and operating systems—using high-level languages, especially functional languages with advanced facilities to abstract and generate code. To be reliable and secure, low-level code must correctly manage space, time, and other resources, so special type systems and verification tools arose to regulate resource access statically. However, a general-purpose functional language practical today can provide the same static assurances, also without run-time overhead. We substantiate this claim and promote the trend with two security kernels in the domain of device drivers: 1. one built around raw pointers, to track and arbitrate the size, alignment, write permission, and other properties of memory areas across indexing and casting; 2. the other built around a device register, to enforce protocol and timing requirements while reading from the register. Our style is convenient in Haskell thanks to custom kinds and predicates (as type classes); type-level numbers, functions, and records (using functional dependencies); and mixed type- and term-level programming (enabling partial type signatures). 1
Extended Static Checking of Call-by-Value Functional Programs
, 2007
"... We present a Hoare logic for a call-by-value programming language equipped with recursive, higher-order functions, algebraic data types, and a polymorphic type system in the style of Hindley and Milner. It is the theoretical basis for a tool that extracts proof obligations out of programs annotated ..."
Abstract
-
Cited by 2 (0 self)
- Add to MetaCart
We present a Hoare logic for a call-by-value programming language equipped with recursive, higher-order functions, algebraic data types, and a polymorphic type system in the style of Hindley and Milner. It is the theoretical basis for a tool that extracts proof obligations out of programs annotated with logical assertions. These proof obligations, expressed in a typed, higher-order logic, are discharged using off-the-shelf automated or interactive theorem provers. Although the technical apparatus that we exploit is by now standard, its application to call-by-value functional programming languages appears to be new, and (we claim) deserves attention. As a sample application, we check the partial correctness of a balanced binary search tree implementation.
Reasoning about Selective Strictness -- Operational Equivalence, Heaps and Call-by-Need Evaluation, New Inductive Principles
, 2009
"... Many predominantly lazy languages now incorporate strictness enforcing primitives, for example a strict let or sequential composition seq. Reasons for doing this include gains in time or space efficiencies, or control of parallel evaluation. This thesis studies how to prove equivalences between pro ..."
Abstract
-
Cited by 1 (0 self)
- Add to MetaCart
Many predominantly lazy languages now incorporate strictness enforcing primitives, for example a strict let or sequential composition seq. Reasons for doing this include gains in time or space efficiencies, or control of parallel evaluation. This thesis studies how to prove equivalences between programs in languages with selective strictness, specifically, we use a restricted core lazy functional language with a selective strictness operator seq whose operational semantics is a variant of one considered by van Eckelen and de Mol, which itself was derived from Launchbury’s natural semantics for lazy evaluation. The main research contributions are as follows: We establish some of the first ever equivalences between programs with selective strictness. We do this by manipulating operational semantics derivations, in
Reasoning about Selective Strictness -- Operational Equivalence, Heaps and Call-by-Need Evaluation, New Inductive Principles
, 2009
"... This thesis studies how to prove equivalences between programs in languages with selective strictness, specifically, we use a restricted core lazy functional language with a selective strictness operator seq. We establish some of the first ever equivalences between lazy programs with selective str ..."
Abstract
- Add to MetaCart
This thesis studies how to prove equivalences between programs in languages with selective strictness, specifically, we use a restricted core lazy functional language with a selective strictness operator seq. We establish some of the first ever equivalences between lazy programs with selective strictness by manipulating operational semantics derivations. Our operational semantics is similar to that used by van Eekelen and De Mol, though we introduce a ‘garbage-collecting’ rule for (let) which turns out to cause expressiveness restrictions. For example, arguably reasonable lazy programs such as let y = λz.z in λx.y do not reduce in our operational semantics. We prove some properties of seq, including associativity, idempotence, and left-commutativity. The proofs use our three notions of program equivalence defined

