Reasoning about multi-stage programs

Inoue, Jun; Taha, Walid

doi:10.1017/s0956796816000253

Cited by 7 publications

(8 citation statements)

References 60 publications

(91 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Although compiler analyses and transformations are (usually) sound, they are almost never complete: a compiler generally offers no guarantee that any optimization will be successfully applied. 11 There are several instances when an innocuous change to a program makes it much slower. The compiler is a black box, with the programmer forced into constantly reorganizing the program in unintuitive ways in order to achieve the desired performance.…”

Section: Discussion: Why Staging?mentioning

confidence: 99%

See 1 more Smart Citation

Stream fusion, to completeness

Kiselyov

Biboudis

Palladinos³

et al. 2017

Proceedings of the 44th ACM SIGPLAN Symposium on Principles of Programming Languages

View full text Add to dashboard Cite

Stream processing is mainstream (again): Widely-used stream libraries are now available for virtually all modern OO and functional languages, from Java to C# to Scala to OCaml to Haskell. Yet expressivity and performance are still lacking. For instance, the popular, well-optimized Java 8 streams do not support the zip operator and are still an order of magnitude slower than hand-written loops.We present the first approach that represents the full generality of stream processing and eliminates overheads, via the use of staging. It is based on an unusually rich semantic model of stream interaction. We support any combination of zipping, nesting (or flat-mapping), sub-ranging, filtering, mapping-of finite or infinite streams. Our model captures idiosyncrasies that a programmer uses in optimizing stream pipelines, such as rate differences and the choice of a "for" vs. "while" loops. Our approach delivers hand-written-like code, but automatically. It explicitly avoids the reliance on black-box optimizers and sufficiently-smart compilers, offering highest, guaranteed and portable performance.Our approach relies on high-level concepts that are then readily mapped into an implementation. Accordingly, we have two distinct implementations: an OCaml stream library, staged via MetaOCaml, and a Scala library for the JVM, staged via LMS. In both cases, we derive libraries richer and simultaneously many tens of times faster than past work. We greatly exceed in performance the standard stream libraries available in Java, Scala and OCaml, including the well-optimized Java 8 streams.

show abstract

Section: Discussion: Why Staging?mentioning

confidence: 99%

“…The combinators of_arr and fold are staged analogously. We use the method of [11] to prove the correctness, which easily applies to this case, given that map is non-recursive. The sample processing pipeline (the first example from §2) As expected, no lists, buffers or other variable-size data structures are created.…”

Section: Simple Staging Of Streamsmentioning

confidence: 99%

Stream fusion, to completeness

Kiselyov

Biboudis

Palladinos³

et al. 2017

Proceedings of the 44th ACM SIGPLAN Symposium on Principles of Programming Languages

View full text Add to dashboard Cite

show abstract

“…Comparing evaluation orders Plotkin [22] and many others (e.g. [8]) relate call-by-value and call-by-name. Crucially, they consider lambda-calculi with no side-effects other than divergence.…”

Section: Related Workmentioning

confidence: 99%

Galois connecting call-by-value and call-by-name

McDermott¹,

Mycroft²

2022

Preprint

View full text Add to dashboard Cite

We establish a general framework for reasoning about the relationship between call-by-value and call-by-name.In languages with side-effects, call-by-value and call-by-name executions of programs often have different, but related, observable behaviours. For example, if a program might diverge but otherwise has no side-effects, then whenever it terminates under call-by-value, it terminates with the same result under call-by-name. We propose a technique for stating and proving these properties. The key ingredient is Levy's call-by-push-value calculus, which we use as a framework for reasoning about evaluation orders. We construct maps between the call-by-value and call-by-name interpretations of types. We then identify properties of side-effects that imply these maps form a Galois connection. These properties hold for some side-effects (such as divergence), but not others (such as mutable state). This gives rise to a general reasoning principle that relates call-by-value and call-by-name. We apply the reasoning principle to example side-effects including divergence and nondeterminism.

show abstract

“…It is always true that this transformation of dropping the staging annotations should recover a valid unstaged program [Inoue and Taha 2016]. It is not always the case that we can just drop staging annotations in the original code to end up with a satisfactory staged version.…”

Section: Unstaged Starting Pointmentioning

confidence: 99%

Staged sums of products

Pickering

Löh²,

2020

Proceedings of the 13th ACM SIGPLAN International Symposium on Haskell

View full text Add to dashboard Cite

Generic programming libraries have historically traded efficiency in return for convenience, and the generics-sop library is no exception. It offers a simple, uniform, representation of all datatypes precisely as a sum of products, making it easy to write generic functions. We show how to finally make generics-sop fast through the use of staging with Typed Template Haskell. CCS Concepts: • Software and its engineering → Functional languages.

show abstract

Reasoning about multi-stage programs

Cited by 7 publications

References 60 publications

Stream fusion, to completeness

Stream fusion, to completeness

Galois connecting call-by-value and call-by-name

Staged sums of products

Contact Info

Product

Resources

About