Embedding Dynamic Dataflow in a Call-by-Value Language

Cooper, Gregory H.; Krishnamurthi, Shriram

doi:10.1007/11693024_20

Cited by 143 publications

(128 citation statements)

References 21 publications

Supporting

Mentioning

128

Contrasting

Order By: Relevance

“…From a semantic perspective, this form of I/O control is closely related to Clean's model of input and output [1]. It is also somewhat reminiscent of the Yale school of functional reactive programming [4,11].…”

Section: Interactive Graphical Programs For Acl2mentioning

confidence: 99%

Automatic verification for interactive graphical programs

Eastlund

Felleisen

2009

Proceedings of the Eighth International Workshop on the ACL2 Theorem Prover and Its Applications

View full text Add to dashboard Cite

Modern software applications come with interactive graphical displays. In the past, verification efforts for such programs have usually ignored the I/O aspects of programs and focused instead on their core functionality. This approach leaves open the question of how errors in the interactive part of the program can affect its overall functionality.In this paper we present an extension of Dracula (the ACL2 development environment for DrScheme) with a simple graphical framework. With Dracula we can automatically prove theorems about interactive graphical programs, guaranteeing their complete behavior. We have successfully verified theorems about a number of interactive programs with Dracula; we have also successfully used Dracula as a motivational tool to introduce students to the world of automated theorem proving. Formal verification has been applied to other forms of I/O; notably, the Sparkle theorem prover can verify a model of concurrent filesystem operations [9]. We go even further and automatically prove correctness theorems about interactive graphical programs. Our approach relies on an event loop with functional callbacks, exploits images as first-class values, and introduces liveness properties. We use ACL2 [16] because it is the most successful industrialstrength theorem prover. Categories and Subject Descriptors1 ACL2 has verified large projects including commercial floating point processors, a complete micro-processor, and a Java virtual machine.In this paper we present Dracula, the first tool providing automatic theorem proving for interactive, graphical programs. The rest of the paper proceeds as follows. We describe the language and user interface of Dracula in section 2 and its graphical toolkit in section 3. Section 4 explains how we prove theorems about Dracula programs, and section 5 details the projects we have verified. We conclude with section 6 on related work and section 7 to summarize our contribution. Dracula [23] is an extension of the ACL2 theorem prover, implemented as a language level in the DrScheme integrated development environment (IDE) [13]. Dracula uses the DrScheme runtime system to simulate ACL2 programs, and the ACL2 theorem prover to reason about them. Every feature of Dracula comes with both an executable behavior and a logical meaning for ACL2. DRACULA: AN IDE FOR ACL2ACL2 stands for "Applicative Common Lisp: a Computational Logic". It consists of a first-order functional language ("Applicative Common Lisp") and a first-order equational logic ("Computational Logic"). The theorem prover infers induction strategies to prove a programmer's conjectures. Figure 1 shows a small program in ACL2 containing a function plus of two arguments and a conjecture plus-natp 1 campus.acm.org/public/pressroom/press_releases/3_ 2006/software.cfm

show abstract

Section: Interactive Graphical Programs For Acl2mentioning

confidence: 99%

Automatic verification for interactive graphical programs

Eastlund

Felleisen

2009

Proceedings of the Eighth International Workshop on the ACL2 Theorem Prover and Its Applications

View full text Add to dashboard Cite

show abstract

“…There exists a number of reactive programming frameworks and libraries for different programming languages, e.g., the Rx (Reactive Extensions) [14] family and Scala.React [15]. With FrTime [16] and Flapjax [17] complete languages based on this paradigm have been created. Our approach of reactive distributed models@run.time is inspired by this increasingly popular programming paradigm and lifts its main ideas and concepts to the level of models.…”

Section: A Reactive Programmingmentioning

confidence: 99%

Stream my models: Reactive peer-to-peer distributed models@run.time

Hartmann

Moawad

Fouquet

et al. 2015

2015 ACM/IEEE 18th International Conference on Model Driven Engineering Languages and Systems (MODELS)

View full text Add to dashboard Cite

Abstract-The models@run.time paradigm promotes the use of models during the execution of cyber-physical systems to represent their context and to reason about their runtime behaviour. However, current modeling techniques do not allow to cope at the same time with the large-scale, distributed, and constantly changing nature of these systems. In this paper, we introduce a distributed models@run.time approach, combining ideas from reactive programming, peer-to-peer distribution, and large-scale models@run.time. We define distributed models as observable streams of chunks that are exchanged between nodes in a peerto-peer manner. A lazy loading strategy allows to transparently access the complete virtual model from every node, although chunks are actually distributed across nodes. Observers and automatic reloading of chunks enable a reactive programming style. We integrated our approach into the Kevoree Modeling Framework and demonstrate that it enables frequently changing, reactive distributed models that can scale to millions of elements and several thousand nodes.

show abstract

“…Moreover, when there is a state change in one computation or data, the programmer is required to manually update all the others that depend on it. Such manual management of state changes and data dependencies is complex and error-prone (e.g., performing state changes at a wrong time or in a wrong order) [Cooper and Krishnamurthi 2006]. Using traditional programming solutions (such as design patterns and event-driven programming), interactive applications are typically constructed around the notion of asynchronous callbacks (event handlers).…”

mentioning

confidence: 99%

A survey on reactive programming

et al. 2013

View full text Add to dashboard Cite

Reactive programming has recently gained popularity as a paradigm that is well-suited for developing event-driven and interactive applications. It facilitates the development of such applications by providing abstractions to express time-varying values and automatically managing dependencies between such values. A number of approaches have been recently proposed embedded in various languages such as Haskell, Scheme, JavaScript, Java, .NET, etc. This survey describes and provides a taxonomy of existing reactive programming approaches along six axes: representation of time-varying values, evaluation model, lifting operations, multidirectionality, glitch avoidance, and support for distribution. From this taxonomy, we observe that there are still open challenges in the field of reactive programming. For instance, multidirectionality is supported only by a small number of languages, which do not automatically track dependencies between time-varying values. Similarly, glitch avoidance, which is subtle in reactive programs, cannot be ensured in distributed reactive programs using the current techniques. INTRODUCTIONToday's applications are increasingly becoming highly interactive, driven by all sorts of events originating from within the applications and their outside environment. Such event-driven applications maintain continuous interaction with their environment, processing events and performing corresponding tasks such as updating the application state and displaying data [Pucella 1998]. The most interactive part of such appli- Author's addresses: Software Languages Lab, Vrije Universiteit Brussel, Pleinlaan 2, 1050 Elsene, Brussels, Belgium; email: ebainomu@vub.ac.be Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies show this notice on the first page or initial screen of a display along with the full citation. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, to republish, to post on servers, to redistribute to lists, or to use any component of this work in other works requires prior specific permission and/or a fee. Permissions may be requested from Publications Dept., ACM, Inc., 2 Penn Plaza, Suite 701, New York, NY 10121-0701 USA, fax +1 (212) 869-0481, or permissions@acm.org. cations is usually the GUI, which typically needs to react to and coordinate multiple events (e.g., mouse clicks, keyboard button presses, multi-touch gestures, etc.).These applications are difficult to program using conventional sequential programming approaches, because it is impossible to predict or control the order of arrival of external events and as such control jumps around event handlers as the outside environment changes unexpectedly (inverted control, i.e., the control flow of a program is driven by external events and not by an order specified by the programmer). Moreo...

show abstract

Embedding Dynamic Dataflow in a Call-by-Value Language

Cited by 143 publications

References 21 publications

Automatic verification for interactive graphical programs

Automatic verification for interactive graphical programs

Stream my models: Reactive peer-to-peer distributed models@run.time

A survey on reactive programming

Contact Info

Product

Resources

About