Modular rollback through control logging

Shivers, Olin; Turon, Aaron

doi:10.1145/2034773.2034783

Cited by 6 publications

(4 citation statements)

References 10 publications

(11 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…When might we want to do that? Let us develop an example, motivated by Shivers and Turon's treatment of modular rollback in parsing (Shivers & Turon, 2011). Consider a high-level interface to an input stream of characters with one-step lookahead.…”

Section: Computations As Datamentioning

confidence: 99%

Doo bee doo bee doo

Convent¹,

Lindley²,

McBride³

et al. 2020

J. Funct. Prog.

View full text Add to dashboard Cite

Abstract We explore the design and implementation of Frank, a strict functional programming language with a bidirectional effect type system designed from the ground up around a novel variant of Plotkin and Pretnar’s effect handler abstraction. Effect handlers provide an abstraction for modular effectful programming: a handler acts as an interpreter for a collection of commands whose interfaces are statically tracked by the type system. However, Frank eliminates the need for an additional effect handling construct by generalising the basic mechanism of functional abstraction itself. A function is but the special case of a Frank operator that interprets no commands. Moreover, Frank’s operators can be multihandlers which simultaneously interpret commands from several sources at once, without disturbing the direct style of functional programming with values. Effect typing in Frank employs a novel form of effect polymorphism which avoids mentioning effect variables in source code. This is achieved by propagating an ambient ability inwards, rather than accumulating unions of potential effects outwards. With the ambient ability describing the effects that are available at a certain point in the code, it can become necessary to reconfigure access to the ambient ability. A primary goal is to be able to encapsulate internal effects, eliminating a phenomenon we call effect pollution. Moreover, it is sometimes desirable to rewire the effect flow between effectful library components. We propose adaptors as a means for supporting both effect encapsulation and more general rewiring. Programming with effects and handlers is in its infancy. We contribute an exploration of future possibilities, particularly in combination with other forms of rich type systems.

show abstract

Section: Computations As Datamentioning

confidence: 99%

Doo bee doo bee doo

Convent¹,

Lindley²,

McBride³

et al. 2020

J. Funct. Prog.

View full text Add to dashboard Cite

show abstract

“…When might we want to do that? Let us develop an example, motivated by Shivers and Turon's treatment of modular rollback in parsing [53].…”

Section: Computations As Datamentioning

confidence: 99%

Do be do be do

LindleySam¹,

McBrideConor²,

McLaughlinCraig³

2017

SIGPLAN Not.

View full text Add to dashboard Cite

We explore the design and implementation of Frank, a strict functional programming language with a bidirectional effect type system designed from the ground up around a novel variant of Plotkin and Pretnar's effect handler abstraction.Effect handlers provide an abstraction for modular effectful programming: a handler acts as an interpreter for a collection of commands whose interfaces are statically tracked by the type system. However, Frank eliminates the need for an additional effect handling construct by generalising the basic mechanism of functional abstraction itself. A function is simply the special case of a Frank operator that interprets no commands. Moreover, Frank's operators can be multihandlers which simultaneously interpret commands from several sources at once, without disturbing the direct style of functional programming with values.Effect typing in Frank employs a novel form of effect polymorphism which avoid mentioning effect variables in source code. This is achieved by propagating an ambient ability inwards, rather than accumulating unions of potential effects outwards.We introduce Frank by example, and then give a formal account of the Frank type system and its semantics. We introduce Core Frank by elaborating Frank operators into functions, case expressions, and unary handlers, and then give a sound small-step operational semantics for Core Frank.Programming with effects and handlers is in its infancy. We contribute an exploration of future possibilities, particularly in combination with other forms of rich type system. Hillerström and Lindley [20-22] (Links [11]) and Leijen [30] (Koka [29]) have extended existing languages with effect handlers and algebraic effects. Both languages incorporate row-based effect type systems and attempt to elide some effect variables from source code, but neither eliminates effect variables to the extent that Frank does. Dolan et al. [12] built Multicore OCaml by extending OCaml with support for effect handlers and algebraic effects. Multicore OCaml does not include an effect type system.Whereas Frank is bidirectionally typed, all of these other languages use Hindley-Milner type inference. None of the other languages supports multihandlers and none of those with effect typing allow effect variables to be omitted to the degree that Frank does.Kammar et al.[25] describe a number of effect handler libraries for languages ranging from Racket, to SML, to OCaml, to Haskell. Apart from the Haskell library, their libraries have no effect typing support. The Haskell library takes advantage of type classes to simulate an effect type system not entirely dissimilar to that of Frank. As Haskell is lazy, the Haskell library cannot be used to write direct-style effectful programs-one must instead adopt a monadic style. Moreover, although there are a number of ways of almost simulating effect type systems in Haskell, none is without its flaws. Kiselyov and collaborators [26,27] have built another Haskell library for effect handlers, making different design choices.Brady's effe...

show abstract

“…We choose to study shift and reset [11] because delimited continuations have proven useful for implementing web servers [25,30], providing processes isolation in operating systems [23], representing computational effects [15], modularly implementing errorcorrecting parsers [35], and finally undelimited continuations are passé for good reason [22]. Even with all their uses, however, their semantics can yield control-flow possibilities that surprise their users.…”

Section: Case Study Of First-class Control: Shift and Resetmentioning

confidence: 99%

Abstracting abstract control

Johnson

Horn

2014

Proceedings of the 10th ACM Symposium on Dynamic Languages

View full text Add to dashboard Cite

The strength of a dynamic language is also its weakness: run-time flexibility comes at the cost of compile-time predictability. Many of the hallmarks of dynamic languages such as closures, continuations, various forms of reflection, and a lack of static types make many programmers rejoice, while compiler writers, tool developers, and verification engineers lament. The dynamism of these features simply confounds statically reasoning about programs that use them. Consequently, static analyses for dynamic languages are few, far between, and seldom sound.The "abstracting abstract machines" (AAM) approach to constructing static analyses has recently been proposed as a method to ameliorate the difficulty of designing analyses for such language features. The approach, so called because it derives a function for the sound and computable approximation of program behavior starting from the abstract machine semantics of a language, provides a viable approach to dynamic language analysis since all that is required is a machine description of the interpreter.The AAM recipe as originally described produces finite state abstractions: the behavior of a program is approximated as a finite state machine. Such a model is inherently imprecise when it comes to reasoning about the control stack of the interpreter: a finite state machine cannot faithfully represent a stack. Recent advances have shown that higher-order programs can be approximated with pushdown systems. However, such models, founded in automata theory, either breakdown or require significant engineering in the face of dynamic language features that inspect or modify the control stack.In this paper, we tackle the problem of bringing pushdown flow analysis to the domain of dynamic language features. We revise the abstracting abstract machines technique to target the stronger computational model of pushdown systems. In place of automata theory, we use only abstract machines and memoization. As case studies, we show the technique applies to a language with closures, garbage collection, stack-inspection, and first-class composable continuations.

show abstract

Modular rollback through control logging

Cited by 6 publications

References 10 publications

Doo bee doo bee doo

Doo bee doo bee doo

Do be do be do

Abstracting abstract control

Contact Info

Product

Resources

About