Copyright 1998 IEEE. Published in the Proceedings of VL’98, Sept. 1-4, 1998 at Halifax, Nova Scotia, Canada. Personal use of this material is permitted.
However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to
servers or lists, or to reuse any copyrighted component of this work in other works, must be obtained from the IEEE. Contact: Manager, Copyrights and
Permissions, IEEE Service Center/445 Hoes Lane/PO Box 1331, Piscataway, NJ 08855-1331 USA.
- 1 -
Implementing Level 4 Liveness
in Declarative Visual Programming Languages
Margaret M. Burnett*,

John W. Atwood, Jr., and Zachary T. Welch
Department of Computer Science, Oregon State University, Corvallis, OR 97331
{burnett, atwoodj, welchza}@cs.orst.edu
Abstract
An increasingly common characteristic in visual
programming languages (VPLs) is level 4 liveness—the
constant monitoring of the system state with continuous
redisplay as events arrive and computations progress.
However, level 4 liveness can be expensive.
In this paper, we present an implementation method
that supports level 4 liveness in declarative VPLs, ensur-
ing without “unreasonable” cost that all values on the
screen are correctly updated as computations progress. The
method is especially well-suited for the growing class of
declarative VPLs that display continuously time-varying
calculations and graphics, such as GUI specification VPLs,
event-based or reactive VPLs, scientific visualization
VPLs, or graphical simulation VPLs.
1. Introduction
Many declarative visual programming languages
(VPLs) today employ immediate visual feedback to
support programming. To categorize the immediacy of
feedback provided, Tanimoto coined the term “liveness,”
which categorizes the immediacy of semantic feedback that
is automatically provided during programming [17].
Tanimoto described four levels of liveness. At level 1
no semantic feedback about a program is provided to the
user, and at level 2 the user can obtain semantic feedback
about a portion of a program, but it is not provided auto-
matically. Interpreters support level 2 liveness. At level 3,
incremental semantic feedback is automatically provided
whenever the user performs an incremental program edit,
and all affected onscreen values are automatically
redisplayed. This ensures the consistency of display state
and system state if the only trigger for system state
changes is user editing. The automatic recalculation feature
of spreadsheets supports level 3 liveness. At level 4, the
system responds to program edits as in level 3, and to
other events as well, such as system clock ticks and mouse
clicks over time, ensuring that all data on display
accurately reflects the current state of the system as
*
This work was supported in part by Harlequin, Inc., and by
NSF under ASC-9523629 and a Young Investigator Award.
computations continue to evolve.
Level 4 liveness supports continuous visualization and
steering of evolving computations, which is particularly
important for declarative VPLs supporting interactive GUI
specification, scientific visualization, and graphical
simulations. In the VPL arena, these problem domains
have been addressed almost entirely by declarative
approaches, especially constraint-based, dataflow, and rule-
based. To support these problem domains in our
declarative spreadsheet VPL, Forms/3 [3, 4], we have been
working on ways to efficiently support liveness at level 4.
In this paper, we discuss a number of implementation
methods for supporting liveness at level 4 in declarative
VPLs, and compare their efficiency. We also present a new
method we have devised, termed “lazy marking with culprit
tracking.” We show that this method is more able than the
others to maintain consistent response times, and that, for
some triggers, it is in fact optimal in the number of
variables1 processed.
1.1 Implementation requirements
To support level 4 liveness, it is necessary to keep the
display state up-to-date even when the program remains
unedited, and it is mainly upon this situation that this
paper focuses. (We defer until Section 7 the discussion of
responding to program edits.)
Even when there are no edits, the display needs to
change in response to four trigger types: (t1) interactions
that change which portion of the program is visible to the
user, such as de-iconifying the window with the graphical
thermometer in Figures 1 or 2; (t2) computational events,
such as a graphical clock that needs to be redrawn after
each “tick”; (t3) user input events, such as clicking on the
F-C button in Figures 1 or 2; and (t4) time travel events,
in which the user manipulates a time control device to
view the program’s state at a different moment in time.
Not all level 4 systems support t4 triggers, but some do,
1The term “variable” is being used for consistency with
traditional programming language literature. Generalizing to
VPLs that do not have explicit variables, “variable” means
any object that might need to be computed to produce and
maintain the program’s output; for example, a spreadsheet cell
or an attribute of a character in a graphical rewrite rule.