Liquid resource types

Knoth, Tristan; Wang, Di; Reynolds, Adam; Hoffmann, Jan; Polikarpova, Nadia

doi:10.1145/3408988

Cited by 7 publications

(5 citation statements)

References 45 publications

(56 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…There are many approaches to type-based cost analysis (Crary & Weirich, 2000; Hofmann & Jost, 2003; Jost et al ., 2010; Hoffmann & Hofmann, 2010; Hoffmann et al ., 2012, 2017; Jost et al ., 2017; Knoth et al ., 2019, 2020; Avanzini & Dal Lago, 2017; ÇiÇek et al ., 2017; Wang et al ., 2017; Dal Lago & Gaboardi, 2011; Handley et al ., 2019; Rajani et al ., 2021). At a high level, these systems include special-purpose judgments or types that track cost, indexed or refinement types that track the size of values, and a type checking or inference mechanism that can automatically determine some resource bounds.…”

Section: Related Workmentioning

confidence: 99%

“…The basic AARA technique has been extended in numerous ways, e.g., with refinement types (Knoth et al . 2019; 2020) for synthesizing programs with desired resource bounds, and for more precise tracking of potential in values. The Timed ML system of Wang et al .…”

Section: Related Workmentioning

confidence: 99%

“…Third, type-based approaches make the size and cost an intrinsic feature of the code: in approaches based on refinement types, one must, for example, define one tree type where size means number of nodes, and a different tree type where size means height, which causes code duplication if both are necessary; in amortized approaches, one must choose the potential annotations when defining a type (though sometimes this can be mitigated by parametrizing the datatypes Knoth et al . 2020). In our approach, cost and size are an extrinisic property of the code, so the same function can be interpreted in different models with different notions of size for different analyses, which can be useful, e.g., for a library function that is used in two different programs by other functions that require two different notions of size.…”

Section: Related Workmentioning

confidence: 99%

See 2 more Smart Citations

Denotational semantics as a foundation for cost recurrence extraction for functional languages

Danner¹,

Licata²

2022

J. Funct. Prog.

View full text Add to dashboard Cite

A standard informal method for analyzing the asymptotic complexity of a program is to extract a recurrence that describes its cost in terms of the size of its input and then to compute a closed-form upper bound on that recurrence. We give a formal account of that method for functional programs in a higher order language with $\mathtt{let}$ -polymorphism. The method consists of two phases. In the first phase, a monadic translation is performed to extract a cost-annotated version of the original program. In the second phase, the extracted program is interpreted in a model. The key feature of this second phase is that different models describe different notions of size. This plays out in several ways. For example, when analyzing functions that take arguments of inductive types, different notions of size may be appropriate depending on the analysis. When analyzing polymorphic functions, our approach shows that one can formally describe the notion of size of an argument in terms of the data that is common to the notions of size for each type instance of the domain type. We give several examples of different models that formally justify various informal cost analyses to show the applicability of our approach.

show abstract

Section: Related Workmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

See 1 more Smart Citation

Denotational semantics as a foundation for cost recurrence extraction for functional languages

Danner¹,

Licata²

2022

J. Funct. Prog.

View full text Add to dashboard Cite

show abstract

“…Subsequent works on the topic [Bengtson et al 2011;Schmid and Kuncak 2016;Vazou et al 2014Vazou et al , 2017 utilise SMT solvers, such as Z3 [De Moura and Bjùrner 2008], to aid the type system to decide a semantic subtyping relation [Bierman et al 2012] using SMT encodings. Refinement types have been applied to numerous domains, such as resource usage analysis [Handley et al 2019;Knoth et al 2020], secure implementations [Bengtson et al 2011;Bhargavan et al 2010], information control flow enforcements , and theorem proving [Vazou et al 2017]. Our aim is to utilise refinement types for the specification and verification of distributed protocols, by combining refinement and session types in a single practical framework.…”

Section: Related Workmentioning

confidence: 99%

Statically verified refinements for multiparty protocols

Zhou

Ferreira

et al. 2020

Proc. ACM Program. Lang.

View full text Add to dashboard Cite

With distributed computing becoming ubiquitous in the modern era, safe distributed programming is an open challenge. To address this, multiparty session types (MPST) provide a typing discipline for message-passing concurrency, guaranteeing communication safety properties such as deadlock freedom.While originally MPST focus on the communication aspects, and employ a simple typing system for communication payloads, communication protocols in the real world usually contain constraints on the payload. We introduce refined multiparty session types (RMPST), an extension of MPST, that express data dependent protocols via refinement types on the data types.We provide an implementation of RMPST, in a toolchain called Session ⋆ , using Scribble, a toolchain for multiparty protocols, and targeting F ⋆ , a verification-oriented functional programming language. Users can describe a protocol in Scribble and implement the endpoints in F ⋆ using refinement-typed APIs generated from the protocol. The F ⋆ compiler can then statically verify the refinements. Moreover, we use a novel approach of callback-styled API generation, providing static linearity guarantees with the inversion of control. We evaluate our approach with real world examples and show that it has little overhead compared to a naïve implementation, while guaranteeing safety properties from the underlying theory. CCS Concepts: • Theory of computation → Automated reasoning; Distributed computing models; • Software and its engineering → Source code generation.

show abstract

“…Some languages like Resource Aware ML [31] aim for full automation, at the cost of struggling to handle some common language features. Other languages like TiML [81] or LRT [42] attempt to strike a balance by giving up on a degree of automation and requiring annotations from the programmer in order to make gains in expressiveness. In contrast to these languages 3 , LambdaAmor emphasizes expressiveness above all else.…”

Section: Introductionmentioning

confidence: 99%

Languages With Potential

Cutler¹

View full text Add to dashboard Cite

While decades of research into formal verification have brought provable correctness guarantees closer to being a part of developers' everyday reality, provable guarantees about algorithmic complexity are harder to come by. This is not for lack of effort. Algorithmic complexity and program cost don't play nicely with abstraction, and so they can prove a difficult target for the kinds of compositional analysis that formal tools handle best. However, the classical algorithm analysis technique known as amortized analysis [75] is promising in this regard: it allows one to selectively break abstraction barriers to precisely and compositionally calculate program costs.In this thesis, we leverage amortized analysis to make two contributions which make some progress towards our goal of provable cost guarantees for the masses.We begin by taking a cue from the interactive theorem proving school of software verification.We develop a functional language called LambdaAmor, which provides a rich refinement type system for in-language amortized cost analysis. We begin with a previously-developed core calculus called λ-Amor [64], transform it to an algorithmic type system which is amenable to implementation, and subsequently implement the language in OCaml.Next, we move to considering a more lightweight method of analyzing the cost of programs, namely the extract-and-solve method of recurrences. This technique is already used (explicitly or otherwise) by practitioners of functional languages, and regularly included in introductory CS curricula. However, the technique is informal, error-prone, and not immediately applicable to amortized cost analysis. Following on work by Danner et al. [19], we formalize the process of amortized analysis by recurrence extraction as a language-to-language translation, and use this to prove the technique's correctness. v 1. INTRODUCTION 7 This is somewhat inaccurate: the presence of a sum construct in the language of index terms breaks linearity, but this is rarely a problem in practice. 8 The ∀j ∶ N... being irrelevant is crucial here: since one cannot pattern match on the value of j, the cost of the computation must be uniform in j.10 Alternatively, this can be thought of as being analogous to width subtyping for records.

show abstract

Liquid resource types

Cited by 7 publications

References 45 publications

Denotational semantics as a foundation for cost recurrence extraction for functional languages

Denotational semantics as a foundation for cost recurrence extraction for functional languages

Statically verified refinements for multiparty protocols

Languages With Potential

Contact Info

Product

Resources

About