One-way, dataflow constraints are commonly used in graphical interface toolkits, programming environments, and circuit applications. Previous papers on dataflow constraints have focused on the design and implementation of individual algorithms. In contrast, this article focuses on the lessons we have learned from a decade of implementing competing algorithms in the Garnet and Amulet graphical interface toolkits. These lessons reveal the design and implementation tradeoffs for different one-way, constraint satisfaction algorithms. The most important lessons we have learned are that (1) mark-sweep algorithms are more efficient than topological ordering algorithms; (2) lazy and eager evaluators deliver roughly comparable performance for most applications; and (3) constraint satisfaction algorithms have more than adequate speed, except that the storage required by these algorithms can be problematic.

Universities around the world have modified their computer engineering curricula to include courses and modules focusing on the design of embedded systems including reconfigurable hardware, real-time processing, embedded processors, and firmware/software systems. This paper describes a different approach to embedded systems education-the development of an embedded systems track within an existing computer science program. This approach allows for an intentionally designed balance of computer science, computer engineering, mathematics, and science courses deemed necessary for a comprehensive embedded systems program.

Most one-way constraint solvers use directed dataflow graphs to represent the dependencies among variables in a constraint. Unfortunately, dataflow graphs require a great deal of storage. These storage costs can help push a large application into virtual memory, thus significantly degrading interactive performance. Reducing the storage costs of dataflow graphs is therefore an important goal in constraint research. This paper describes a study that makes two contributions to solving this problem:1. It examines dataflow graphs in actual applications and reports their characteristics. One of the principal findings is that over 90% of the dependencies in most applications are neighborhood dependencies that refer to slots in the same object, its parent, its children or its siblings.2. It examines how two approaches for reducing the storage costs of dataflow graphs-Hudson and Smith's constraints and a pure model dependency scheme that we devisedwork in practice. Both approaches attempt to implicitly represent neighborhood dependencies. The results are discouraging. constraints eliminate fewer than 10% of the explicit dependencies in a typical application and our scheme eliminates roughly 20%. One of the principal findings is that the formulas which generate the most dependencies do not exclusively use neighborhood dependencies. Thus the schemes should be modified so that they can accommodate non-neighborhood dependencies.

Dataflow constraints allow programmers to easily specify relationships among application objects in a natural, declarative manner. Most constraint solvers represent these dataflow relationships as directed edges in a dataflow graph. Unfortunately, dataflow graphs require a great deal of storage. Consequently, an application with a large number of constraints can get pushed into virtual memory, and performance degrades in interactive applications. Our solution is based on the observation that objects derived from the same class use the same constraints, and thus have the same dataflow graphs. We represent the common dataflow patterns in a model dataflow graph that is stored with the class. Instance objects may derive explicit dependencies from this graph when the dependencies are needed. Model dependencies provide a useful new mechanism for improving the storage efficiency of dataflow constraint systems, especially when a large number of constrained objects must be managed.

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...