Using model dataflow graphs to reduce the storage requirements of constraints

Zanden, Bradley T. Vander; Halterman, Richard L.

doi:10.1145/502907.502910

Cited by 3 publications

(1 citation statement)

References 31 publications

(54 reference statements)

Supporting

Mentioning

Contrasting

Order By: Relevance

“…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].…”

mentioning

confidence: 99%

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

mentioning

confidence: 99%

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

show abstract

Graphic Rendering Considered as a Compilation Chain

Tissoires

Conversy

2008

Interactive Systems. Design, Specification, and Verification

View full text Add to dashboard Cite

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

Using model dataflow graphs to reduce the storage requirements of constraints

Cited by 3 publications

References 31 publications

Lessons learned from programmers' experiences with one-way constraints

Lessons learned from programmers' experiences with one-way constraints

Graphic Rendering Considered as a Compilation Chain

Reactive Imperative Programming with Dataflow Constraints

Contact Info

Product

Resources

About