Lessons learned about one-way, dataflow constraints in the Garnet and Amulet graphical toolkits

Zanden, Bradley T. Vander; Halterman, Richard L.; Myers, Brad A.; McDaniel, Rich; Miller, Rob; Szekely, Pedro; Giuse, Dario A.; Kosbie, David S.

doi:10.1145/506315.506318

Cited by 24 publications

(33 citation statements)

References 29 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…This choice is better suited to our framework and, as previous experience has shown, lazy and eager evaluators typically de-liver comparable performance in practice [46]. Eager evaluation is achieved as follows.…”

Section: Memory Model and Execution Modesmentioning

confidence: 99%

“…Hence, if a system of constraints is acyclic, then our solver always converges to the correct result, without the need for programmers to prove any stabilization properties of their constraints. This is the most common case in many applications [6,19,34], and several efficient techniques can be adopted by constraint solvers to automatically detect cycles introduced by programming errors [46]. In addition to the acyclic case, our abstract machine can also handle the most general case of cyclic constraints embedded within an imperative program.…”

Section: Cyclic Vs Acyclic Systems Of Constraintsmentioning

confidence: 99%

“…If y is modified from outside the constraint, the equation is left temporarily unsatisfied, hence the attribute "one-way". Dataflow constraints are recognized as a powerful programming methodology in a variety of contexts because of their versatility and simplicity [46]. The most widespread application of dataflow constraints is perhaps embodied by spreadsheets [2,36].…”

Section: Introductionmentioning

confidence: 99%

“…This programming style is intuitive and readily accessible to a broad range of developers [46]. The ability to smoothly combine different paradigms in a unified framework makes it possible to take advantage of different programming styles in the context of the same application.…”

Section: Introductionmentioning

confidence: 99%

“…The ability to smoothly combine different paradigms in a unified framework makes it possible to take advantage of different programming styles in the context of the same application. The problem of integrating imperative and dataflow programming has already been the focus of previous work in the context of specific application domains [11,40,41,46]. Previous mixed imperative/dataflow systems are based on libraries of ad hoc data types and functions for representing constraint variables and for binding the imperative program to the constraint solver.…”

Section: Introductionmentioning

confidence: 99%

See 4 more Smart Citations

Reactive Imperative Programming with Dataflow Constraints

Demetrescu

Finocchi

Ribichini

2014

ACM Trans. Program. Lang. Syst.

View full text Add to dashboard Cite

Dataflow languages provide natural support for specifying constraints between objects in dynamic applications, where programs need to react efficiently to changes of their environment. Researchers have long investigated how to take advantage of dataflow constraints by embedding them into procedural languages. Previous mixed imperative/dataflow systems, however, require syntactic extensions or libraries of ad hoc data types for binding the imperative program to the dataflow solver. In this paper we propose a novel approach that smoothly combines the two paradigms without placing undue burden on the programmer.In our framework, programmers can define ordinary statements of the imperative host language that enforce constraints between objects stored in special memory locations designated as "reactive". Differently from previous approaches, reactive objects can be of any legal type in the host language, including primitive data types, pointers, arrays, and structures. Statements defining constraints are automatically re-executed every time their input memory locations change, letting a program behave like a spreadsheet where the values of some variables depend upon the values of other variables. The constraint solving mechanism is handled transparently by altering the semantics of elementary operations of the host language for reading and modifying objects. We provide a formal semantics and describe a concrete embodiment of our technique into C/C++, showing how to implement it efficiently in conventional platforms using off-the-shelf compilers. We discuss common coding idioms and relevant applications to reactive scenarios, including incremental computation, observer design pattern, and data structure repair. The performance of our implementation is compared to ad hoc problem-specific change propagation algorithms, as well as to language-centric apPermission to make digital or hard copies of all or part 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 bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. OOPSLA'11, October 22-27, 2011, Portland, Oregon, USA. Copyright c 2011 proaches such as self-adjusting computation and subject/observer communication mechanisms, showing that the proposed approach is efficient in practice.

show abstract

Section: Memory Model and Execution Modesmentioning

confidence: 99%

Section: Cyclic Vs Acyclic Systems Of Constraintsmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Reactive Imperative Programming with Dataflow Constraints

Demetrescu

Finocchi

Ribichini

2014

ACM Trans. Program. Lang. Syst.

View full text Add to dashboard Cite

show abstract

Lessons learned from programmers' experiences with one-way constraints

Zanden

Halterman

Myers

et al. 2005

Softw: Pract. Exper.

Self Cite

View full text Add to dashboard Cite

One-way constraints have been incorporated in many graphical user interface toolkits because they are simple to learn, easy to write, and can express many types of useful graphical relationships. This paper is an evaluative paper that examines users' experience with one-way constraints in two user interface development toolkits, Garnet and Amulet, over a 15-year time span. The lessons gained from this examination can help guide the design of future constraint systems. The most important lessons are that (1) constraints should be allowed to contain arbitrary code that is written in the underlying toolkit language and does not require any annotations, such as parameter declarations, (2) constraints are difficult to debug and better debugging tools are needed, and (3) programmers will readily use one-way constraints to specify the graphical layout of an application, but must be carefully and time-consumingly trained to use them for other purposes. 1276 B. T. VANDER ZANDEN ET AL.interfaces [1][2][3][4][5][6][7][8][9][10][11]. In turn these implementations have spawned many articles describing algorithms for solving these constraints or evaluating the trade-offs among these algorithms [5,[11][12][13][14][15][16][17].A pair of 'retrospective' papers have also been published recently that report on longer-term experiences with constraints. A companion paper to this one provides an empirical comparison of the performance and design trade-offs of various constraint satisfaction algorithms based on our experiences with the toolkits described in this paper [18]. A second paper mentions briefly two of the observations described in this paper: (1) the fact that programmers have found constraints useful for graphical layout and (2) the fact that many programmers find constraints somewhat difficult to master in other settings due to their declarative, rather than imperative, nature [19]. However, it provides no documentary evidence for these observations, does not explore them in any detail, and does not report the other findings reported in this paper.Despite the wealth of papers on one-way constraints, none of them has provided an in-depth account of programmers' experiences with these constraints after the toolkits have been released and in use for several years. This paper remedies that gap in the literature. It describes: (1) what programmers like and dislike about constraints; (2) how programmers use constraints in applications; and (3) how we learned to make constraints easier for programmers to use. The results are based on 15 years of experience gained from working with users of the Garnet and Amulet toolkits [3,4] and from surveys of these users. Garnet is a Lisp-based toolkit for developing interactive graphical applications that was first released in 1989 and Amulet is a C++-based successor to Garnet that was released in 1994. Garnet can be downloaded from . Both toolkits incorporate one-way constraints and have been used by over 1000 programmers. Garnet runs on the Unix and Macintosh platforms, and Amulet runs on t...

show abstract