Back to a Half-Century Later:
"From Sketchpad61 to Sketchpad14"
Part II: Constraints as a Design Pattern (CDP) in Sketchpad14

Hesam Samimi, Alex Warth
Communications Design Group

53 Years Later: Sketchpad14

Overveld's alternative relaxation constraint solving approach for the geometric constraints a la Sketchpad inspired us to build a fully general programming model around it. We call it Sketchpad14. Our intention was to go back and honor and implement most of the cool things about Sutherland's Sketchpad, yet build a realistic system to build interactive web applications, declaratively. Our main observations were:

As in Sketchpad and Overveld's geometric constraints, the way to define and modify the behavior of a program is to add/remove constraints, rather than the common imperative programming practice of "adding or modifying some code." We take Overveld's approach, however, and require that the statement and the solution to individual constraint types be defined beforehand. This means we let the user define constraint types as well as how to solve them in isolation. This setup puts the programmer in the driver seat to use the programming language of the program itself to define the constraint and also provide an "algorithm" to solve it. Note that there's nothing stopping that algorithm to be simply an invocation of an external solver!

Another aspect of Sketchpad14 is that it gives a principled mechanism for the user to define the reactive part of an interactive program. The next section explains a semi-formal programming model implemented by the tool that we call Constraints as a Design Pattern.

Constraints as a Design Pattern

Sketchpad14 is hosted in JavaScript, so we will explain the Constraints as a Design Pattern (CDP) model in the context of the JS language.

In this language, primitive types as well as functions and objects serve as values. Objects can be instantiated and referenced, as usual. However, imperative style programming, e.g. assignments and looping constructs for computation, isn't done.

Constructing a program in the CDP model involves describing four parts:

An event is defined by:

The model restricts what can be done in a handler, and it will be primarily used to add/remove data or continuous constraints to/from the store. Another thing that can occur in the event handler is a discrete constraint, i.e. one that is only solved once at the time the event is triggered, but it doesn't get added to the store with the rest of the continuous constraints.

Therefore, the execution model is unlike the imperative style, i.e., statement by statement. The program is assumed to be reactive. All present constraints are assumed to be continuously operating over the data, affecting them any time they are left unsatisfied. The events are always assumed to be ready to be triggered.

OK, enough talking! We'll come back to CDP later. Let's jump to some Sketchpad14 examples in the next part.

Read Part III: Using Sketchpad14 with Predefined Types
Back to Table of Contents