scholarly journals GhostCell: separating permissions from data in Rust

2021 ◽  
Vol 5 (ICFP) ◽  
pp. 1-30
Author(s):  
Joshua Yanovski ◽  
Hoang-Hai Dang ◽  
Ralf Jung ◽  
Derek Dreyer

The Rust language offers a promising approach to safe systems programming based on the principle of aliasing XOR mutability : a value may be either aliased or mutable, but not both at the same time. However, to implement pointer-based data structures with internal sharing, such as graphs or doubly-linked lists, we need to be able to mutate aliased state. To support such data structures, Rust provides a number of APIs that offer so-called interior mutability : the ability to mutate data via method calls on a shared reference. Unfortunately, the existing APIs sacrifice flexibility, concurrent access, and/or performance, in exchange for safety. In this paper, we propose a new Rust API called GhostCell which avoids such sacrifices by separating permissions from data : it enables the user to safely synchronize access to a collection of data via a single permission. GhostCell repurposes an old trick from typed functional programming: branded types (as exemplified by Haskell’s ST monad), which combine phantom types and rank-2 polymorphism to simulate a lightweight form of state-dependent types. We have formally proven the soundness of GhostCell by adapting and extending RustBelt, a semantic soundness proof for a representative subset of Rust, mechanized in Coq.

2004 ◽  
Vol 14 (4) ◽  
pp. 429-472 ◽  
Author(s):  
BRIAN MCNAMARA ◽  
YANNIS SMARAGDAKIS

We describe the FC++ library, a rich library supporting functional programming in C++. Prior approaches to encoding higher order functions in C++ have suffered with respect to polymorphic functions from either lack of expressiveness or high complexity. In contrast, FC++ offers full and concise support for higher-order polymorphic functions through a novel use of C++ type inference. The FC++ library has a number of useful features, including a generalized mechanism to implement currying in C++, a “lazy list” class which enables the creation of “infinite data structures”, a subtype polymorphism facility, and an extensive library of useful functions, including a large part of the Haskell Standard Prelude. The FC++ library has an efficient implementation. We show the results of a number of experiments which demonstrate the value of optimizations we have implemented. These optimizations have improved the run-time performance by about an order of magnitude for some benchmark programs that make heavy use of FC++ lazy lists. We also make an informal performance comparison with similar programs written in Haskell.


Author(s):  
WOUTER SWIERSTRA ◽  
PETER DYBJER

There has been sustained interest in functional programming languages with dependent types in recent years. The foundations of dependently typed programming can be traced back to Martin–Löf's work in the 1970s. In the past decades, this vision has given rise to the development of proof assistants and functional programming languages based on dependent types. The increased popularity of systems such as Agda, Coq, Idris, and many others, reflects the growing momentum in this research area. After sending out our first call for papers in October 2015, we are happy to accept six articles in this special issue covering a wide spectrum of topics.


2014 ◽  
Vol 6 (2) ◽  
pp. 147-157
Author(s):  
Konrad Grzanek

Abstract Directed acyclic graphs and trees in particular belong to the most extensively used data structures. Visualizing them properly is a key to a success when developing complex algorithms that make use of them. Textual visualizations a la UNIX tree command is essential when the urge is to deal with large trees. Our aim was to design a library that would exploit this approach and to make an implementation of it for a purely functional programming language. The library uses monads to print directly into an output stream or to generate immutable Strings. This paper gives a detailed overview of the solution.


2013 ◽  
Vol 23 (2) ◽  
pp. 145-160
Author(s):  
MARK P. JONES

AbstractWe describe a concise and elegant functional program, written in Haskell, that computes solutions for a classic puzzle known as the “snake cube.” The program reflects some of the fundamental characteristics of the functional style, identifying key abstractions, and defining a small collection of operators for manipulating and working with the associated values. Well-suited for an introductory course on functional programming, this example highlights the use of visualization tools to explain and demonstrate the choices of data structures and algorithms that are used in the development.


2005 ◽  
Vol 16 (1) ◽  
pp. 21-34 ◽  
Author(s):  
MARTIN ERWIG ◽  
STEVE KOLLMANSBERGER

At the heart of functional programming rests the principle of referential transparency, which in particular means that a function f applied to a value x always yields one and the same value y=f(x). This principle seems to be violated when contemplating the use of functions to describe probabilistic events, such as rolling a die: It is not clear at all what exactly the outcome will be, and neither is it guaranteed that the same value will be produced repeatedly. However, these two seemingly incompatible notions can be reconciled if probabilistic values are encapsulated in a data type.


2014 ◽  
Vol 25 (7) ◽  
pp. 1546-1568
Author(s):  
JARRYD P. BECK ◽  
JOHN PLAICE ◽  
WILLIAM W. WADGE

Although the language Lucid was not originally intended to support computing with infinite data structures, the notion of (infinite) sequence quickly came to the fore, together with a demand-driven computation model in which demands are propagated for the values of particular values at particular index points. This naturally generalized to sequences of multiple dimensions so that a programmer could, for example, write a program that could be understood as a (nonterminating) loop in which one of the loop variables is an infinite vector.Programmers inevitably found use for more and more dimensions, which led to a problem which is fully solved for the first time in this paper. The problem is that the implementation's cache requires some estimate of the dimensions actually used to compute a value being fetched. This estimate can be difficult or (if dimensions are passed as parameters) impossible to obtain, and the demand-driven evaluation model for Lucid breaks down.We outline the evolution of Lucid which gave rise to this problem, and outline the solution, as used for the implementation of TransLucid, the latest descendant of Lucid.


Sign in / Sign up

Export Citation Format

Share Document