Developing a Estage Lightin System

8/10/2019 Developing a Estage Lightin System

http://slidepdf.com/reader/full/developing-a-estage-lightin-system 1/12

Developing a Stage Lighting System from Scratch

Michael SperberWilhelm-Schickard-Institut fur Informatik

Universitat [email protected]

ABSTRACT

Lula is a system for computer-assisted stage lighting designand control. Whereas other systems for the same purposeare usually the results of long chains of incremental improve-ments of historic concepts, Lula represents a complete re-design. Whereas other systems focus on control aspects of lighting, Lula focuses on design and generates control in-formation from it. This approach gives significantly moreflexibility to the lighting designer and shortens the designprocess itself.

Lula’s design and implementation draw from a numberof disciplines in advanced programming. It is written inScheme and runs atop PLT Scheme , and benefits from its

high-level GUI library. Lula uses an algebraic model forlighting looks based on just three combinators. It employsFunctional Reactive Programming for all dynamic aspectsof lighting, and is programmable via a functional-reactivedomain-specific language.

Lula is an actual product and has users who have neitherinterest in nor knowledge of functional programming.

1. THE DEMANDS OF STAGE LIGHTINGLive shows require lighting. This applies to theater, but

also to concerts and industrial presentations. Lighting astage well is surprisingly hard. Modern stage lighting pre-scribes multiple colored light sources for a single place onstage. Even though the complexity of the lighting is often

not apparent to the spectator, the diff erence between whitehead-on lighting and a setup which takes into account mod-elling, focus, environmental representation, mood, temper-ature, etc. is striking. This makes lighting design a difficultcraft and an art with recognized masters [17, 20].

The demands of the craft have produced a stunning ar-senal of technology available to today’s lighting designer:Modern intelligent lighting fixtures (or just fixtures for short)have electronic controls for intensity, direction, focus, color,beam shape, and many other parameters. Their practicaluse requires computerized control systems.

Permission 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 arenot made or distributed for pro£t or commercial advantage and that copiesbear this notice and the full citation on the £rst page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior speci£cpermission and/or a fee.

ICFP’01, September 3-5, 2001, Florence, Italy.Copyright 2001 ACM 1-58113-415-0/01/0009 ...$5.00.

Sofa

DeskLab table

Lab table

Figure 1: Set groundplan for Doctor Love .

Lighting Looks. Consider a simple lighting session in a

theatrical setting. The basic ingredients are a stage withprops and actors, and simple theatrical fixtures with variableintensity. The play is Doctor Love : Doctor Love, a madscientist, is working on a new hybrid virus which attacksboth humans and computer programs written in functionallanguages. Her assistant, Frederick Thirst, has to do most of the computer programming while Doctor Love works mostlyat the bio lab during alternate shifts. Between them, one of them usually sleeps on a sofa in the lab. During the course of the play, Thirst discovers the beauty of functional languagesand convinces Doctor Love to abandon her evil plan. As thesun rises, they fall in love on the sofa. End of play.

Figure 1 shows the set groundplan. The director sets thefollowing requirements for the lighting:

• The main acting areas —gravitational centers for theactors’ movements—are on the chair behind the desk,the two lab tables, the sofa, and on the downstagecenter area between the desk and the lab tables.

• When Doctor Love emits her evil laugh, always behindthe upstage lab table, she must look particularly evil.

• The contrast between the normal, sterile lighting dur-ing most of the play and the sunrise at the end mustbe very strong and visible.

A lighting designer, faced with these requirements, will usu-ally start by lighting the basic acting areas: the chair be-hind the desk, the sofa and the two lab tables, and the cen-ter. Each such area will need several fixtures pointed at

it to ensure good illumination and facial modelling, pos-sibly with diff ering intensities. The designer will proba-bly light the two lab tables separately. Additionally, shemight place footramps under the downstage lab table for theFrankenstein-type evil-laugh lighting. A number of yellow-orange backlights provide the sunrise lighting.



These basic lighting components appear in a variety of combinations as lighting looks during the play: Basic, neu-tral lighting is a simple combination of the desk-area light-ing, the sofa, the lab table lighting (itself consisting of twosubcomponents), and the center area. Monologues mightdim down all but one of these components to highlight aparticular area. Special combinations include the evil-laughlook and the sunrise.

Technically, all of these lighting looks are merely inten-sity specifications for the stage fixtures—if the fixtures arenumbered with indices, looks are simply vectors of intensi-ties. However, it is immediately obvious that the intentionsof the lighting designer carry a hierarchical structure.

Design Goals. Most commercial lighting control systemsonly support the construction of lighting components withdepth two, and do not store their hierarchical structure atall. At present, only two consoles support hierarchical mod-elling for lighting looks, but their usage is discouraged byinflexible user interfaces, intricate semantic issues and in-sufficient documentation [3, 9]. The eff ect is that existingsystems represent looks at the control or implementation level rather than at the conceptual level of the design. Infact, the schism between these two levels bears striking simi-larities to the diff erence between imperative and declarativeprogramming.

Therefore, the major goal of Lula is a more faithful repre-sentation of the structure of a lighting design. This requires

re-examining all basic design premises of existing systems,and has resulted in a complete redesign of the very conceptof the lighting control system: Lula has been developed fromscratch, both implementation-wise and conceptually.

Lula also tries to address another shortcoming of existingsystems: These systems exhibit significant non-linearitiesbetween the user-interface controls and the actual situationon stage. Lighting designers often find themselves operatinga control on the console and wondering, why nothing hap-pens on stage, or why something diff erent happened fromwhat they expected. As a result, Lula’s lighting compo-nent model is based on a rigorous formal specification. Thisspecification is the basis for Lula’s internal data representa-tions, but, more importantly, determines the structure of itsgraphical user interface. The uniformity of the specificationis not a guarantee, but a necessary prerequisite and goodindicator for the usability of the interface.

This Paper. The faithful representation of the structureof lighting looks, described in Sections 2, 3, and 4 is themain innovation of Lula, and hence the main topic of thispaper. Another central aspect of the system is its treatmentof animated lighting, which builds upon Functional ReactiveProgramming, described in Section 5. The paper brieflyreviews substrate considerations in Section 6, and experiencegained in practice in Section 7.

2. BUILDING CUES

Consider the hierarchical structure of the lighting looks assuggested by the play as shown in Figure 2. The sofa, for ex-ample, has three fixtures pointing at it hooked to electricalchannels 7, 14, and 23, at some specified intensity. Simi-larly, the ellipses under the other basic components standfor some combinations of electrical channels and the intensi-

. . . . . . . . . . . .

. . . . . .

Sun Desk Sofa Center Lab tables

DS Lab tables US Lab tables

Frankenstein

Basic

Sunrise Evil Laugh

7 14 23

Figure 2: Partial cue structure of Doctor Love .

ties of their fixtures. The “Lab tables” components has twosubcomponents, each of which itself consists of subcompo-nents. The hierarchy builds up with the “Basic” componentsfor the basic stage look, and the “Sunrise” look consistingof a dimmed version of “Basic” and added “Sun” lighting,and the “Evil Laugh” look which features the Frankensteinfootramp and again dimmed basic lighting.

The resulting structure of the lighting components is a di-rected acyclic graph, and it is desirable that a lighting designsystem support manipulating such graphs. Lula calls staticlighting components cues (a somewhat unfortunate term inretrospect, but it has stuck). The simplest cues representsingle electrical channels. More complex cues consist of sev-eral subcues which might themselves have more structure.In lighting designs more realistic than the example presentedhere, the dag is often significantly deeper.

Note that cues correspond to conceptual entities in thelighting design rather than “implementation details” likewhat fixture performs what function or to which electricalcircuit it is connected. Fixtures occur only at the leaves of the dag structure. Above the leaf level, the dag is indepen-dent of the concrete stage. This is an essential step forwardfrom current commercial systems which ignore the structureand represent only the individual parameter settings

The example design above involves only one single, addi-tive operator for cue composition: The fixtures involved inlighting the “Lab tables” cue are the union of the fixturesin “DS Lab tables” and “US Lab tables” at their respec-tive intensities. If both component cues share a fixture, the

compound cue has the fixture at the maximum of the in-tensities in the component cues, a principle called Highest Takes Precedence or HTP in the industry.

Two other combinators besides HTP have proven usefulfor cue construction in practice:

• Cue subtraction removes a set of fixtures from a cue.This is useful when talking about cues that result fromother cues by taking parts away: “The entire stagewithout the upstage-left corner,” for example.

• Cue restriction combines two component cues in asimilar way as HTP does, but behaves diff erently forshared fixtures: one of the two cues has precedence forspecifying the intensities of shared fixtures. This oc-curs in situations like “The entire stage, but with thekitchen table darker than the rest.”

The cue language is eff ectively a domain-specific language (DSL) [22]. It has methodological similarities to Haskore [12]and recent work in using combinator languages to describefinancial contracts [13].



2.1 Simple Cue TermsInitially, it is easiest to consider a setting with exclusively

theatrical fixtures which only have intensity control. How-ever, the concepts presented here extend straightforwardlyto multi-parameter fixtures. Section 4 shows how.

The basic algebra for cues builds on three primitive sorts:The cue sort is for cues themselves. factor represents ascalar factor; the scale function uniformly scales the inten-sity of a cue. Moreover, fixture represents a fixture, with anassumed constant for every fixture. Here is a signature forthe operations on cues:

fromfixture : fixture → cue scale : factor × cue → cue black : cue : cue × cue → cue : cue × cue → cue

\ : cue × cue → cue

The black cue denotes darkness. The scale function scalesthe intensity of a cue by some factor. (Presumably, thesignature would also contain constructors for factor values.These were omitted for brevity.)

The fromfixture constructor converts a fixture into a cuecontaining only that fixture at maximum intensity. Thecombinators , , and \ are HTP, restriction, andcue diff erence, respectively.

2.2 Carrier Sets for CuesUltimately, the goal is to construct an equational specifi-

cation for the cue operators in the previous section. Sincethe cue operators originate from the application domainwhere they already have fixed semantics, I first formalize thesemantics, and backtrack from there to the specification.

A cue conceptually consists of a set of fixtures that arepart of the cue, and intensities for these fixtures. The “cuecontains fixture” notion is explicit: The model distinguishesbetween a cue c which does not contain some fixture f anda cue c which diff ers from c only by including f at zerointensity. The resulting algebra is called A0.

An intensity is a non-negative real number, bounded bysome maximum value M :

I := R0,+

≤M

Its carrier set A0 fixture for fixture contains elements for all

fixtures. A0cue is a set with:

A0cue ⊆ P (A0

fixture)× (A0 fixture I)

A0 fixture I is the set of partial functions from A0

fixture toI. A cue must define intensities for exactly the fixtures itcontains. Hence, A0

cue is the largest set fulfilling the abovecondition as well as:

(F, p) ∈ A0cue ⇐⇒ F = dom( p).

Factors are non-negative real numbers:

A0 factor := R

0,+

2.3 Semantics of CuesThe next step in constructing A0 is assigning meaning to

its constants and operators. The black cue is easiest:

blackA0

:= (∅,∅)

The fromfixture constructor assembles a cue from a singlefixture at its maximum intensity:

fromfixtureA0

(f ) := ({f }, {f → M })

The scale function scales all fixtures in a cue uniformly:

scaleA0

(µ, (F, p)) := (F, p) where p(f ) := min(µ · p(f ),M )

The HTP combinator merges the fixtures involved, and as-signs maximal intensities:

(F 1, p1) A0

(F 2, p2) := (F 1 ∪ F 2, p)

where p(f ) := p1(f ) for f ∈ F 2

p2(f ) for f ∈ F 1

max( p1(f ), p2(f )) otherwise

Restriction also merges the fixtures involved, but gives prece-dence to the intensities of the second cue:

(F 1, p1) A0

(F 2, p2) := (F 1 ∪ F 2, p)

where p(f ) :=

p1(f ) for f ∈ F 2

p2(f ) otherwise

The diff erence combinator is the set-theoretic diff erence be-tween the fixtures contained in the operand cue:

(F 1, p1) \A0

(F 2, p2) := (F 1 \ F 2, p1|F 1\F 2)

3. AXIOMS AND THEOREMS FOR CUESThe A0 algebra has a number of pleasant properties which

will form an axiomatic basis for the specification. The proofsof the axioms and theorems presented are straightforwardand have been omitted for brevity [21]. Here are the threemost immediate axioms1:

3.1 AxiomHTP is commutative and associative.

3.2 AxiomHTP and restriction are idempotent. For every cue c:

c A0

c = c

c A0

c = c

3.3 AxiomFor any cue c:

c A0

blackA0

= c (1)

c A0

blackA0

= c (2)

black A0

c = c (3)

c \A0

blackA0

= c (4)

blackA0

\A0

c = blackA0

(5)

c \A0

c = blackA0

(6)

1They are called axioms here because they are axioms inthe resulting specification. At this point, they still requireproofs of their validity in A0. The theorems, in contrast, areexclusively derived from the axioms.



Restriction is expressible in terms of HTP and diff erence:

3.4 LemmaFor any cues a and b:

a A0

b = (a \A0

b) A0

b

Moreover, \ and have some of the properties of their set-theoretic counterparts:

3.5 AxiomThe following equations hold for all cues a, b, and c:

(a A0

b) \A0

c = (a \A0

c) A0

(b \A0

c) (7)

a \A0 (b A0c) = (a \A0

b) \A0c (8)

(a \A0

b) \A0

c = (a \A0

c) \A0

b (9)

(a \A0

b) \A0

c = (a \A0

(b \A0

c)) \A0

c (10)

3.6 TheoremRestriction is associative. For all cues a, b, and c:

a A0

(b A0

c) = (a A0

b) A0

c

3.7 TheoremRestriction left-distributes over HTP. For cues a, b , c:

(a A0

b) A0

c = (a A0

c) A0

(b A0

c)

Note that restriction does not right-distribute over HTP.Finally, a number of trivial axioms concern the interaction

of scaling with the various cue combinators:

3.8 AxiomFor any factor µ and cues a and b:

scale(µ, black) = black (11)

scale(µ, a b) = scale(µ, a) scale(µ, b) (12)

scale(µ, a b) = scale(µ, a) scale(µ,b) (13)

scale(µ, a \ b) = scale(µ, a) \ b (14)

3.1 Differentiating Cues and Fixture SetsThe definition of cue diff erence is somewhat ugly: it im-

plicitly disregards the intensity specifications of its secondargument, treating it as a mere set of fixtures. Making thedistinction between a cue and its fixture set explicit yieldsanother cue operator: the complement . For a cue c, thecomplement yields a cue which contains exactly those fix-tures not contained in c. Besides making the specificationslightly more pleasant, this step also has practical bearingon the use of the specification for the construction of Lula’sgraphical user interface, as I will show later.

The new signature for cue terms includes an new sort fixtureset for fixture sets:

fromfixture : fixture → cue scale : factor × cue → cue black : cue

: cue × cue → cue : cue × cue → cue ↓ : cue → fixtureset

: fixtureset → fixtureset \ : cue × fixtureset → cue

The natural algebra for this signature, A1, is a straightfor-ward modification of A0. Here are the diff erences betweenthe two: First off , fixture sets are sets of fixtures:

A1 fixtureset := P (A1

fixture)

Cue abstraction extracts the first component from a cue:

↓A0

(F, p) := F

The complement has the set-theoretical interpretation:

F := A1 fixture \ F

Thus, subtracting the complement of c, c, works like apply-ing a stencil.

Double complement is the identity on fixture sets:

3.9 AxiomFor any fixture set F , the following holds:

F = F

The semantics of the diff erence operator needs to reflect thechange in signature:

(F 1, p1) \A1

F 2 := (F 1 \ F 2, p1|F 1\F 2)

To avoid overly complicating the presentation and having torewrite all terms involving diff erences, cue abstraction willsometimes be implicit from here on. With this notationalagreement, all axioms of Section 3 hold as before. In A1,

another axiom holds:3.10 AxiomFor cues a, b, and c, the following equation holds:

a \A1

(b \A1

c) = (a \A1

b) A1(a \A

1

c)

Actually, it would be easier to make statements about diff er-ence if the intersection operator from set theory were avail-able. However, intersection does not have clear intuitivemeaning when applied to lighting. Section 3.2 contains morediscussion of this issue.

3.2 A Domain-Theoretic Interpretation of CuesDenotational semantics uses partial orderings on the el-

ements of semantic domains to distinguish the amount of

information they contain [10]. From a conceptual stand-point, lighting works in a similar way: the more light thereis on stage, the more is visible to the audience.

Consequently, it is possible to define an ordering on cues,induced by the HTP operator:

a b :⇐⇒ a b = b

The meaning of the operator becomes clearer when relatedto the semantics:

(F 1, p1) A1

(F 2, p2) :⇐⇒

F 1 ⊆ F 2 and p1(f ) ≤ p2(f ) for all f ∈ F 1

Thus, a b means that all fixtures contained in a are alsocontained in b and shine at least as bright as in b. Therefore,a b is pronounced “a is at least as dark as b” or “b is atleast as bright as a.”

3.11 Theorem is a partial order.



This makes a least upper bound. It is possible to drive theanalogy between cues and semantic domains even further:

3.12 TheoremCues form a complete partial order in A1: every ω-chain in

A1cue has a least upper bound.

Here is another straightforward correspondence of the cuealgebra with semantic domains:

3.13 TheoremHTP and restriction are continuous in both arguments.

The relationship with domains ends with the diff erence op-

erator which is continuous in its first but not in its secondargument. This is hardly surprising as, conceptually, diff er-ence removes information from a cue.

Note also that fixture sets are a natural abstraction of cues in a domain-theoretic sense—cues and fixture sets forma Galois connection [10].

The domain-theoretic interpretation of cues has no greatrelevance in the intensity-only setting. However, it is acrucial ingredient in formulating the extension to multi-parameter fixtures.

4. MULTI-PARAMETER FIXTURESThe equational specification so far is surprisingly specific

to fixtures which allow intensity control only. Non-intensity

parameters require a more elaborate treatment, both in theimplementation and in the formal specification. There aretwo reasons for this:

• Intensity is qualitatively diff erent from other parame-ters: If the intensity is zero, no change to any of theother parameters is visible. On the other hand, every change in intensity is visible, at least in principle.

• Even though most numeric parameters do have a lim-ited parameter range, they mostly do not have an ev-ident ordering. (Is a color a with a higher proportionof red than another color b larger or smaller?)

Applying the semantic view to a lighting installation withmulti-parameter light helps find a principle for resolving the

problem. This principle translates fairly directly into a newalgebraic specification for cues.The domain-theoretic interpretation of cues assumes that,

for any two cues a and b, a least upper bound a b exists:a b is a cue which reveals everything a and b reveal. a bis at least as bright as both a and b.

This view is not powerful enough for handling multi-pa-rameter fixtures: Even though every fixture in a cue a mightbe brighter than every fixture in cue b, the fixtures mightpoint in diff erent directions, therefore revealing some otherthing entirely, and leaving the target of a in the dark.

The specification of diff erent settings for a non-intensityparameter in the same cue term is called a conflict . Such cueterms do not correspond to well-defined parameter settings.Consequently, two cues a and b containing multi-parameter

fixtures can only be comparable if the non-intensity param-eters of all fixtures included in a and b have the same set-tings. This means that not all pairs of cues have least upperbounds. Furthermore, not all pairs of cues have HTPs: abdoes not exist if a and b share fixtures with diff erent settingsfor non-intensity parameters.

Thus, the domain-theoretic interpretation yields a precisenotion of conflicts. This is in sharp contrast with existinglighting control systems which do not notify the user of con-flicts at all, and only off er ad-hoc mechanisms for resolvingthem. In contrast, Lula informs the user when she tries tointroduce a conflict into the cue hierarchy, and gives (basedon the specification below) detailed information about thesource of the conflict.

In the absence of conflicts, all results from the intensity-only case carry over to multi-parameter fixtures.

4.1 Modelling Parameter TransformationsBesides the issue of conflict, the introduction of multi-

parameter fixtures requires generalizing the notion of scal-ing to arbitrary transformations of parameters. Intensityscaling stands for a function from intensity values to inten-sity values. Similarly, all transformations represent functionfrom parameter values to parameter values. Here are someexamples beside intensity scaling:

Color Set A color-set transformation sets the color of allfixtures in a cue that allow color control.

Pan/Tilt Set A pan/tilt-set transformation sets the panand tilt parameters of all moving lights of a cue.

X/Y/Z Set An X/Y/Z-set transformation sets stage coor-dinates for the moving lights of a cue to focus on.

X/Y/Z Off set An X/Y/Z-set transformation moves the

light beams of moving lights by an off

set in the hori-zontal plane at the specified Z coordinate. This is use-ful, for example, to correct light positioning on dancerswith a preprogrammed choreography.

Each transformation is specific to a certain parameter, andapplies uniformly to all the fixtures in a cue.

As the operator assembles cues by applying transforma-tions and applying the cue combinators, transformations ac-cumulate in two diff erent ways:

Composition arises when a transformed cue is transformedagain: the two transformations compose functionally.

Juxtaposition arises from the HTP combination of twocues which contain a common fixture. For two in-tensity transformations, juxtaposition produces theirleast upper bound. For non-intensity parameters, jux-taposition is only meaningful in the absence of con-flicts.

The introduction of these two concepts justifies separatingout the specification of transformations into their own spec-ification. The next subsection shows how composition and juxtaposition interact with the cue combination operators.

The signature for transformations only supports param-eters for intensity and pan/tilt. However, adding furtherparameters is completely analogous. The signature diff eren-tiates between sorts for specific transformations for intensityand pan/tilt—itrafo and pttrafo and general transformationstrafo.

The ◦ operators are composition operators for transfor-

mations of individual parameters. is for juxtapositionof intensity transformations. A transformation in trafo isconceptually a tuple of an intensity transformation and apan/tilt transformation: the # operator assembles one fromits components. The operator composes two transforma-tions; is for juxtaposition.



scale : factor → itrafoitrafo : itrafo◦itrafo : itrafo × itrafo → itrafo : itrafo × itrafo → itrafo

pan/tilt : angle × angle → pttrafopttrafo : pttrafo◦pttrafo : pttrafo × pttrafo → pttrafo

# : itrafo × pttrafo → trafo : trafo × trafo → trafo : trafo × trafo → trafo

Juxtaposition is conceptually a partial function; hence, it

uses a special exception value notrafo in the trafo sort trafo.Presumably, the scale constructor builds intensity-scale

transformations from scale values, pan/tilt constructs trans-formations that set pan/tilt from two angle values. More-over, itrafo and pttrafo are special constants meaning “nointensity (or no pan/tilt, respectively) transformation spec-ified.”

Transformations obey the following laws:

itrafo ◦itrafo i = ii ◦itrafo itrafo = ipttrafo ◦pttrafo p = p p ◦pttrafo pttrafo = p(i1# p1) (i2# p2) = (i1 ◦itrafo i2)#( p1 ◦pttrafo p2)

itrafo i = ii1 i2 = i2 i1

(i1#pttrafo) (i2# p) = (i1 i2)# pt1 t2 = t2 t1 p1 = pttrafo, p2 = pttrafo =⇒ (i1# p1) (i1# p2) = notrafo

The propagation of the notrafo exception value is implicit.It may seem strange that the specification does not al-

low composing two identity pan/tilt transformations. Thisrestriction reflects Lula’s user interface which distinguishesbetween the absence of a transformation and the presence of an identity transformation. Otherwise, the user could createa conflict simply by operating the slider associated with apan/tilt transformation, which is not desirable.

Finding an algebra A2 for this equational specification is

straightforward: transformations are functions with specialvalues for the constructors added.

Intensity transformations are mappings from intensitiesto intensities plus a bottom value. The constructors cor-respond semantically to bottom values, hence the symbolschosen for A2:

A2itrafo := (I → I) + {⊥pttrafo}

itrafo := ⊥itrafo

A2 uses distinguished values for the constructors ratherthan the identity on the associated parameters. This inturn is to reflect the conflicts of the specification in themodel which also is the basis for conflict detection in theimplementation in Lula.

The scale function applies an intensity transformation inA1 receives a new meaning in A2: it turns a factor into afunction which scales intensity values:

scaleA2

(µ)(i) := min(µ · i, M )

The definition of A2pttrafo is analogous to that of A2

itrafo: Apan/tilt setting consists of two angles.

A2angle := R

0,+

≤2π

A2pttrafo := ((A2

angle × A2angle) → (A2

angle × A2angle)) + {⊥pttrafo}

pttrafo := ⊥pttrafo

The pan/tilt operator constructs a constant function:

pan/tiltA2

(ap, at) := (ap, at)

For non-bottom intensity transformations i1 and i2 or pan/tilt transformations p1 and p2, composition is simply func-tional composition:

i1 ◦A2

itrafo i2 := i1 ◦ i2

p1 ◦A2

pttrafo p2 := p1 ◦ p2

As an aside, note that, even if scaling is the only transfor-mation available for intensities, it is not possible to repre-sent a scaling transformation by its factor, and thus achievecomposition of two intensity-scaling transformation by mul-tiplication of their factors. To see why, consider the cue

term:

apply(scale(0.5), apply(scale(2), fromfixture(f )))

Composition by factor multiplication would pleasantly re-duce this to:

apply(scale(1), fromfixture(f ))

and, hence, fromfixture(f ). Unfortunately, this is wrong:There is no such thing as “double maximum intensity” for areal fixture. Hence, apply(scale(2), fromfixture(f )) is equiv-alent to fromfixture(f ) in a faithful model. Compositionalityreally does require that the example term has f only at half the maximum intensity.

To get back to defining compositions for intensity andpan/tilt transformations, the two bottoms are neutral withrespect to composition as in the specification:

i ◦A2

itrafo ⊥itrafo := i

⊥itrafo ◦A2

itrafo i := i

p ◦A2

itrafo ⊥pttrafo := p

⊥itrafo ◦A2

pttrafo p := p

Intensity transformations allow juxtaposition via formingthe least upper bound:

(i1 i2)(v) := max(i1(v), i2(v))



Finally, a transformation really is a tuple of an intensity

and a pan/tilt transformation. Also, trafoA2

contains anexception element called trafo :

A2trafo := (itrafo × pttrafo) + { trafo}

notrafoA2

:= trafo

Composition of two transformation works by pointwise com-position and must take care to preserve exceptions:

(i1, p1) A2

(i2, p2) := (i1 ◦A2

itrafo i2, p1 ◦A2

pttrafo p2)

trafo A2

t := trafo

t A2

trafo := trafo

Juxtaposition also works as in the specification:

(i1,⊥pttrafo) A2

(i1, p) := (i1 A2

i2, p)

(i1, p) A2

(i1,⊥pttrafo) := (i1 A2

i2, p)

(i1, p1) A2

(i1, p2) := trafo for p1, p2 = ⊥pttrafo

trafo A2

t := trafo

t A2

trafo := trafo

4.2 Modelling Multi-Parameter CuesThe new signature for cues with pan/tilt fixtures is an

extension of the signature for transformations. The partsnot related to the application of an intensity scale are largelyunchanged.

Dealing with conflicts requires considerably more elabo-ration on the semantics of cues on the part of the specifi-cation:a conflict happens at the level of a parameter settingfor a single fixture, so the specification needs to define howcues define parameter settings.To this end, the signature has

a new sort setting . A setting is an association of a fixturewith a transformation.In the new signature, at setting has, for a fixture f and a

transformation t, the form f @t, pronounced “f is at t.”The → operator relates a cue c with a setting s: c → s

means that c specifies a setting s. The pronunciation of c → f @t is “c has f at t.” Here is the signature:

@ : fixture × trafo → setting → : cue × setting → bool

fromfixture : fixture → cue apply : trafo × cue → cue black : cue : cue × cue → cue

: cue × cue → cue ↓ : cue → fixtureset

: fixtureset → fixtureset \ : cue × fixtureset → cue

Here is an equational specification for the new operators:

apply(t,black) = blackapply(t, a b) = apply(t, a) apply(t, b)apply(t, a b) = apply(t, a) apply(t,b)apply(t, a \ b) = apply(t, a) \ bapply(t1, apply(t2, c)) = apply(t1 t2, c)

apply(t, fromfixture(f )) → f @ta → f @t1 ∧ b → f @t2 =⇒ (a b) → f @(t1 t2)a → f @t1 ∧ ¬(∃t2.b → f @t2) =⇒ (a b) → f @t1b → f @t =⇒ (a b) → f @ta → f @t1 ∧ ¬(∃t2.b → f @t2) =⇒ (a b) → f @t1a → f @t1 ∧ ¬(∃t2.b → f @t2) =⇒ (a \ b) → f @t1

The rules for apply look much like the rules for scale inthe old specification. However, there is an additional ruleexplaining the composition of transformations in terms of composition of its components.

The rules for apply are able to propagate transformationsto the leaves of a cue term, the fromfixture terms. More-over, the composition rule for apply allows squashing severalnested transformations into one.

In turn, the → relation infers an obvious setting for a fix-ture from a leaf term of the form apply(t, fromfixture(f )).The other rules propagate settings upwards inside compoundcues. This upwards propagation works only through the reg-ular cue combinators, not through transformation applica-tions. Hence, inferring setting information for the fixtures

contained in a cue means first pushing the transformationsinwards, squashing them there and inferring setting infor-mation for the fixture leaf nodes, and then propagating thesettings back outwards.

Building an algebra A2 for the specification is more in-volved than the construction of A1. First off , A2 includesA1 unchanged. The construction of the cue carrier mustmap fixtures to transformations instead of intensities as inA1. A well-defined cue must only have defined transforma-tion. An exceptional transformation, when part of a cue,produces an exceptional cue. The new A2

cue is a set with:

A2cue ⊆ (P (A2

fixture)× (A2 fixture (A2

trafo \ { trafo})) + { cue}

As above, A2cue must also fulfill the following condition:

(F, p) ∈ A2cue ⇐⇒ F = dom( p).

The black cue has the same meaning as before:

blackA2

:= (∅,∅)

A single-fixture cue has only an undefined transformationassociated with it:

fromfixtureA2

(f ) := ({f }, {f → (⊥itrafo,⊥pttrafo)})

The setting constructor @ is simple tupling:

A2setting := A

2trafo

f @t := (f, t)

Application of a transformation treats all fixtures containedin a cue uniformly:

applyA2

(t, (F, p)) := (F, p) with p (f ) := t A2

p(f )

Of the cue combinators, HTP is the most interesting as it



involves the juxtaposition of transformation, and, therefore,the potential for conflicts:

(F 1, p1) A2(F 2, p2) := (F 1 ∪ F 2, p)

where p(f ) :=

p1(f ) for f ∈ F 2

p2(f ) for f ∈ F 1

p1(f ) A2

p2(f ) otherwise

This definition is only valid if all p1(f ) A2

p2(f ) involveddo not produce an exception. If juxtaposition does producea transformation exception, the HTP is undefined, signalinga conflict:

(F 1, p1) A2(F 2, p2) := cue

if there is an f ∈ F 1 ∩ F 2 with p1(f ) A2

p2(f ) = trafo

Restriction and diff erence basically work as before:

(F 1, p1) A0

(F 2, p2) := (F 1 ∪ F 2, p)

where p(f ) :=

p1(f ) for f ∈ F 2

p2(f ) otherwise

(F 1, p1) \A0

(F 1, p1) := (F 1 \ F 2, p|F 1\F 2)

Relating settings to cues is straightforward in A2:

(F, p) →A2

(f, t) :⇐⇒ f ∈ F and p(f ) = t

4.1 TheoremA2 is a model of the equational specification.

4.3 A Graphical User Interface for CuesNaturally, ordinary users prefer not to deal with algebraic

constructs. Therefore, Lula off ers a simple graphical userinterface for constructing and editing cues. This is madepossible by another algebraic result about the equivalenceof cue terms to terms with bounded height:

4.2 Definition

Assume constants c1, . . . , cn : cue . An atom is either one of the ci or a term of the form fromfixture(f ) for a fixture constant f .

A flat cue term has the following form:

ni=1

si

where each of the si is either an atom or has one of the following two forms:

a1 a2 . . . ani with a1, . . . , ani

atoms

a1 \

a2 · · · \

ani

with a1, . . . , ani atoms

Each ai is either ai itself or its complement ai. The di ff

er-ence operator is assumed to be left-associative.

The fundamental result associated with flat cue form is thatevery cue term has one:

4.3 TheoremAgain assume has constants c1, . . . , cn : cue . For each cue term t, there exists a flat cue term t equivalent to t. More-over, it is possible to choose t such that it contains the same atoms as t.

Proof By term rewriting, using the axioms and theoremsof the previous sections.

Figure 3: Cue editor.

Figure 4: Cue editor displaying a restriction page.

Flat cue form, along with other properties such as asso-ciativity or commutativity, corresponds directly to desirableproperties of a graphical user interface. Hence, the design of Lula’s editor widget for cues is based directly upon cue flat

form. Figure 3 shows such a cue editor widget. In Lula, eachcue has a name (Sofa in this case, taken from yet anotherplay) and the user constructs new cues in flat cue form whereeach atom in the sense of Definition 4.2 is either a fixture oranother named cue together with a set of transformations.

The white area on the left represents an si subterm, a so-called page in the terminology of Lula: it is a list box show-ing the atomic subcues. There are three kinds of pages, HTP,Restriction, and Difference. The latter two corresponddirectly to the form of the si subterms in Definition 4.2; HTP

pages represent terms of the form a1 a2 . . . ani This is

in trivial accordance with Theorem 4.3. These terms havetheir own page type because HTP is the most common formof cue combination.

The list box on the right displays available fixtures, the

white box to its left displays a list of already-defined cues;it is a tree widget, and the user can expand the hierarchicaldisplay by clicking on the little triangles. The cue editorshows an HTP page with three subcues at diff erent inten-sities. The slider in the middle changes the intensities of selected subcues.



Figure 4 shows a cue editor displaying a restriction page.Here, the first cue has a special role. All subsequent cuesmay have a complement operator applied to it: the user canclick on the little box to the left of the Window cue to togglethe complement.

5. ANIMATING LIGHTINGWhile cues are the cornerstones of lighting design, they do

not cover the time element in a show: The lighting designfor a theatrical performance usually consists of a sequence of cues with transitions (so-called fades ) between them. How-

ever, the real animated lighting extends far beyond fadesbetween cues: even in theater, the lighting might have tochange dynamically, concerts often involve animated multi-parameter fixtures with impressive moving eff ects.

Lula internally expresses all light changes as animationsin term of Functional Reactive Programming or FRP . Func-tional Reactive Programming is a programming techniquefor representing values that change over time and react toevents. It is suitable for a wide range of applications, amongthem graphics animations as pioneered by Elliott’s Fran sys-tem [2], graphical user interfaces [19], and robotics [16]. Asit turns out, it is also applicable to animated lighting.

For constructing complex animations, the user has directaccess to FRP via a built-in domain-specific programminglanguage called Lulal , a restricted dialect of Scheme. Lulalallows the construction of reusable components for anima-tions which are accessible through a simpler graphical userinterface, enabling even non-programmers to design theirown animations. This section builds on the terminology of FRP [2].

5.1 PresetsLighting animations build upon cues as their static com-

ponents. Procedurally, the user constructs a library of cueswith the graphical user interface presented in the previoussection, and then uses these as the building blocks for ani-mated lighting. A lighting animation can create looks thatdo not correspond to any cue the user has created: many

animation operators, such as fades, have no counterpart inthe cue language. Moreover, off ering the HTP operator inthe animation language is dangerous, as it may lead to un-predictable conflicts at inopportune times. Therefore, theprimitive static entity in Lulal is not the cue, but the preset .Just like a cue, it specifies fixture parameter settings, andevery cue is also a preset. Presets diff er from cues in the setof operations available for their construction.

The key ingredient for the representation of animatedlighting is the preset behavior , a specialized representationfor presets changing over time. Lulal off ers a rich algebrafor constructing preset behaviors, as well as traditional re-striction and diff erence operators on presets, but no HTP.

5.2 The Lulal LanguageLulal is a higher-order, purely functional, strongly typed

language with parametric polymorphism. Lulal’s syntax ismostly borrowed from Scheme [14]. As its semantics alsobuilds upon Scheme, the description of Lulal in the sectionis brief and focuses on the diff erences.

The design of Lulal makes a number of departures fromScheme syntax and semantics which gear Lulal more specif-ically towards its use in an end-user application. Most of them are restrictions on Scheme semantics to prevent anaverage user from making unnecessary mistakes. Here is asummary of the changes:

• No side eff ects.

• Explicit recursion is not allowed.

• Lulal is strongly typed. Its type system is a modifiedversion of the popular Hindley/Milner system [1]. Thisrestricts expressiveness somewhat, but catches manycommon programming errors before the actual show.

• The language allows a limited form of overloading of constant values with constant behaviors.

• Lulal has additional syntax for dealing with the taskmonad, similar to Haskell’s do notation [11].

• Cues are predefined objects in Lulal, represented by astring literal containing its name.

Lulal’s value domain includes behaviors, events, and tasksfor constructing reactive values. To simplify the work of theprogrammer, Lulal allows a limited form of overloading: avalue of a base time is also overloaded as the correspond-ing constant behavior. This results in a programming stylesimilar to programming Fran animations in Haskell [2].

Tasks represent actions to be done in the reactive frame-work: a task defines a preset behavior as well as a time atwhich it ends.

Tasks form a monad [23], a special value domain for repre-senting computations. Lulal’s use of monads for represent-ing tasks is similar to the one in used in Monadic Robotics[16]. Lulal supports the usual monadic combinators return

and bind as well as a Haskell-do-like sequence operator.Within the monad, the Lulal semantics propagate two val-ues: the start time of a task’s action as well as the presetdefined by the previous action at its end.

FRP Primitives. Lulal’s basic facilities for FRP are similarto Fran’s: it has lifted versions of the standard numerical op-erations, integral and derivative behaviors, a primitive time

behavior, and time transformation.Moreover, the user has access to the usual FRP event alge-

bra with primitive event constructors from alarm times andGUI components, as well as the usual event-handling com-binators, the usual switcher and stepper procedures forconverting events into behaviors, as well as event merging.

Preset Behaviors. In an animated setting, presets gener-alize naturally to preset behaviors . In Lulal, cues define theprimitive preset behaviors. A string literal is implicitly a ref-erence to a cue. The behavior associated with a cue changesits value whenever the user modifies the cue. Lulal con-tains a subset of the primitives available for cue construc-tion: restrict-with is the lifted restriction operator, and

subtract is the lifted diff erence.

Transformation Behaviors. A Lulal program can obtainnew lighting animations by applying transformation behav-iors to preset behaviors. A number of constructors for suchtransformations are available:



Intensity Lulal treats behaviors of reals as intensity trans-formation behaviors.

Pan/tilt The pan/tilt constructor builds a pan/tilt trans-formation behavior from a tuple of two behaviors of reals, specifying the pan and tilt angles, respectively.It is also possible to construct a pan/tilt transforma-tion behavior from three Cartesian coordinate behav-iors via a constructor called xyz. Xyz-offset createsa behavior which shifts the target of a light beam ina specified horizontal plane by two behaviors of the Xand Y coordinates.

Color A number of constructors are available for making

color transformation behaviors from behaviors speci-fying the RGB, HSV, or CMY components.

Applying Transformations. A number of combinators cre-ate new preset behaviors by combining transformation be-haviors with preset behaviors: the result is a preset behaviorresulting from the application of the values of the transfor-mation behavior to those of the preset behaviors. Scale

scales the intensity of a preset behavior by a real behavior.With-pan/tilt applies the pan/tilt transformations result-ing from a pan/tilt transformation behavior; with-color

does the same with a color transformation behavior.

5.3 Tasks

Tasks are the top-level entities in Lulal relevant to theuser: When the user specifies an action that triggers an ani-mation, she must specify a task defined by the Lulal programwhich describes the animation.

A task defines a preset behavior as well as an event whosefirst occurrence signals completion of the action of the task.The user can combine arbitrary preset behaviors with eventsto form tasks. In addition, Lulal provides fades as primitivetasks. The user can combine tasks by sequencing or runningthe actions side-by-side.

5.4 ExampleConsider the following lighting assignment: A moving

light follows an actor on stage. Another one follows thefirst one with a two-second delay. Another one follows with

a four-second delay.Assume that some sensory equipment is hooked up to the

console which reports the actor’s p osition. Further assumethe procedure get-position returns a behavior tuple whichreports the X, Y, and Z coordinates of the actor’s head (orwhatever portion of his body should be lit). Here is anexpression yielding an appropriate task:

(let* ((position (get-position))

(later-position

(time-transform position

(delayed time -2.0)))

(even-later-position

(time-transform later-position

(delayed time -2.0))))

(preset-behavior->task(restrict-with

(with-pan/tilt (xyz position) "Followspot #1")

(restrict-with

(with-pan/tilt (xyz later-position)

"Followspot #2")

(with-pan/tilt (xyz even-later-position)

"Followspot #3")))))

Time is the primitive time behavior. Delayed time-trans-forms a behavior by shifting it. Preset-behavior->task

directly turns a preset behavior into a task that never ends.

Figure 5: Script editor showing final light fade.

Figure 6: Start of playback.

5.5 Assembling a ShowFRP (or, as a matter of fact, any kind of programming)

is not for every user of a lighting control system. Thus,it is crucial to make the flexibility aff orded by Lulal avail-able to these user and to the designer of dynamic lightingcomponents, but hide it from the user who merely wants toassemble a show from cues, fades and prefabricated pieces.

Figure 5 shows Lula’s script editor . It is essentially a sim-ple multimedia editor (based directly on powerful compo-nents already provided by the PLT Scheme system) whichallows pasting events into a script. An event correspondsto an event on stage which requires a coordinated lightingchange.



Figure 5 shows the final lighting event of a simple show, afade-to-black which takes 8 seconds. Each event can trigglemultiple lighting changes simultaneously, arranged sequen-tially or in parallel.

Since the multimedia editor allows including ordinary textand images, it can, for example, hold the playscript of a the-atrical production. This has proved to be tremendous ad-vantage as compared with traditional systems, where light-ing events carry numbers which the operator needs to coor-dinate with numbers written in a paper version of the script.

Figure 6 shows the beginning of playback during a show:the script editor splits to show the progress of the lightingevents in the bottom half. Lula off ers numerous opportu-nities for manual intervention: the operator can suspendlighting changes, interrupt and abort actions as well as slowdown or speed up the animation. Most of the GUI controlsare directly hooked up to FRP components; this has madethe implementation extremely simple.

Figure 7: Eff ect event in script window.

Figure 7 shows how the user can access programmed ani-mations written in Lulal: she simply specifies a term whichyields a lighting task.

6. SUBSTRATE CONSIDERATIONSLula is written in Scheme and runs top PLT Scheme [4].

The feature set of PLT Scheme makes it suitable for appli-cation development in general and for Lula in particular:

• concurrent threads of execution,

• a GUI framework portable between X Windows, Mi-crosoft Windows, and MacOS [7, 6] which includes acollection of GUI widgets for multimedia editors,

• a higher-order, fully-parameterized module system [5],

• an object system supporting parametric inheritancevia mixins [8],

• the Zodiac framework [15] for building scanners andparsers for Scheme-like languages.

In particular, multithreading and the portable GUI frame-work are enabling technologies for applications like Lula.

This combination is still fairly rare in functional-languageimplementations. If functional languages are to succeed inthe marketplace, more implementations must provide thiskind of application-level support.

Two aspects of PLT Scheme have proved somewhat moreproblematic for Lula:

• PLT Scheme uses a non-incremental garbage collec-tor. Machines have only recently become fast enoughmake GC pauses short enough to not cause noticeabledelays during complex lighting animations. (However,straightforward linear animations runs just fine on a133-Mhz Pentium.)

• Threads are not particularly lightweight—each threadtakes up about 20kBytes. This precludes some pro-gramming styles that depend on threads being ex-tremely cheap (such as the use CML-style synchronousoperations [18]), and some eff ort was necessary to keepthe number of threads down, particularly in the sam-pling subsystem and in the user interface.

All in all, however, PLT Scheme has proven an excellentsubstrate for the development of Lula.

7. LULA IN PRACTICELula has been in development since 1997. It has sincebeen in constant use in the University Theater, and has anumber of users there. It has toured with Theater U34,a local theater outfit, to a number of venues in Tubingen,Reutlingen, Stuttgart, and Munich. It has also been in useat Stuttgart State Theater by the lighting designers there.

In theatrical use, Lula drastically cuts down on the timeusually needed for programming the control system, oftenby a factor of two or more. This is significant since thetime spent on programming the control system is usuallynot available for set construction or rehearsal. Moreover,allows the lighting designer or director to communicate thestructure of the lighting design prior to the on-stage phase.The time saved immediately translates to better designs.

Lula is especially eff ective for touring productions: Sinceit allows separating the conceptual components of a designfrom its implementation, the operator can preserve largeparts of the programming between venues. In this environ-ment, the use of Lula can dramatically improve the lightingbecause the time available on-stage is usually very limited.

The response from users has been uniformly positive. TheUniversity Theater has seen a successful bootstrap of thesystem and conducts its own workshops on the use of thesystem, taught by operators rather than computer program-mers. This takes about two hours on the average for groupsof 4–12; after that, the participants are on their own, andusually do well. Results are especially good when we teachlighting design in conjunction with the use of the system, as

the principles of both go hand in hand.Perhaps surprisingly, experienced lighting operators findit harder to get used to Lula than beginners, mainly becauseof their long exposure to traditional lighting control systemand the resulting assumptions about how “a lighting con-sole works.” They initially try to use Lula as they use atraditional system, and are disappointed when they see nosignificant immediate improvement. These designers needto see Lula applied to an existing design to see its benefits.

The animated lighting component of Lula is still underdevelopment. We expect similar results in that arena.

8. CONCLUSION

Lula is a powerful system for lighting design and control.Its main departure from existing systems is its modelling of the conceptual structure of a lighting design rather than itsimplementation. This simplifies input and editing of lightingdesigns, and greatly improves the flexibility of the result ascompared with existing systems.



Both design and the implementation have benefited fromthe use of advanced software engineering techniques:

• The use of a functional wide-spectrum language hasgreatly shortened development time. The first proto-type of Lula (presented at CeBIT ’97) was finished in just under a week.

• The rigorous algebraic model for cues and its domain-theoretic interpretations have been instrumental in cre-ating a consistent and powerful user interface for cre-ating and editing cues.

• The embedded DSL approach, pioneered in the func-

tional programming community is pervasive in Lula,both in the design of the cue algebra and the anima-tion subsystem.

• Functional Reactive Programming is an ideal techniquefor expressing lighting animation.

The outward design of Lula mirrors its internal structure.Consequently, Lula demonstrates that modern functional

language substrates are eminently suitable for applicationdevelopment.

Availability. A demo of the current stable Lula system isavailable under http://www-pu.informatik.uni-tuebingen.

de/lula/.

Acknowledgments. I would like to thank the anonymousreviewers for their excellent comments which were instru-mental in revising the paper.

9. REFERENCES

[1] Damas, L., and Milner, R. Principal type-schemesfor functional programs. In Proc. 9th Annual ACM Symposium on Principles of Programming Languages (1982), ACM, pp. 207–212.

[2] Elliott, C., and Hudak, P. Functional reactiveanimation. In Proc. International Conference on Functional Programming 1997 (Amsterdam, TheNetherlands, June 1997), M. Tofte, Ed., ACM Press,

New York.[3] ETC, Inc. Obsession II User Manual , version 4 ed.

Middleton, Wisconsin, 1998. Available electronicallyas http://www.etcconnect.com/user_manuals/

consoles/obsn_4.pdf.

[4] Felleisen, M., Findler, R. B., Flatt, M., and

Krishnamurthi, S. The DrScheme project: Anoverview. SIGPLAN Notices 33 , 6 (June 1998), 17–23.

[5] Flatt, M., and Felleisen, M. Units: Cool modulesfor HOT languages. In Proceedings of the 1998 ACM SIGPLAN Conference on Programming Language Design and Implementation (PLDI) (Montreal,Canada, June 1998), K. D. Cooper, Ed., ACM,pp. 236–248. Volume 33(5) of SIGPLAN Notices.

[6] Flatt, M., and Findler, R. B. PLT Framework:GUI Application Framework . Rice University,University of Utah, Aug. 2000. Version 103.

[7] Flatt, M., and Findler, R. B. PLT MrEd:Graphical Toolbox Manual . Rice University, Universityof Utah, Aug. 2000. Version 103.

[8] Flatt, M., Krishnamurthi, S., and Felleisen, M.

Classes and mixins. In Proc. 25th Annual ACM Symposium on Principles of Programming Languages (San Diego, CA, USA, Jan. 1998), L. Cardelli, Ed.,ACM Press, pp. 171–183.

[9] Flying Pig Systems Ltd. WHOLEHOG II Handbook , version 3.2 ed. London, UK, 1999. Availableelectronically as http://www.flyingpig.com/Hog2/

cgi/ftp.cgi?file=pub/nils/hogIIv3_2.pdf.

[10] Gunter, C. A. Semantics of Programming Languages: Structures and Techniques . Foundations of Computing. MIT Press, Cambridge, MA, 1992.

[11] Haskell 98, a non-strict, purely functional language.

http://www.haskell.org/definition, Dec. 1998.[12] Hudak, P., Makucevich, T., Gadde, S., and

Whong, B. Haskore music notation — an algebra of music —. Journal of Functional Programming 6 , 3(May 1996), 465–483.

[13] Jones, S. P., Eber, J.-M., and Seward, J.

Composing contracts: An adventure in financialengineering. In Wadler [24], pp. 280–292.

[14] Kelsey, R., Clinger, W., and Rees, J. Revised5

report on the algorithmic language Scheme.Higher-Order and Symbolic Computation 11, 1 (1998),7–105. Also appears in ACM SIGPLAN Notices 33(9),September 1998.

[15] Krishnamurthi, S. Zodiac: A framework for buildinginteractive programming tools. Tech. Rep. TechnicalReport CS TR 95-262, Rice University, Department of Computer Science, 1995.

[16] Peterson, J., Hager, G., and Hudak, P. Alanguage for declarative robotic programming. InProceedings of the International Conference on Robotics and Automation Information 1999 (Detroit,Michigan, May 1999), Y. F. Zheng, Ed., IEEE Press.

[17] Reid, F. The Stage Lighting Handbook , third ed. A &C Black, London, England, 1987.

[18] Reppy, J. H. Synchronous operations as first-classvalues. In Proc. Conference on Programming Language Design and Implementation ’88 (Atlanta, Georgia,July 1988), ACM, pp. 250–259.

[19] Sage, M. FranTk — a declarative GUI language for

Haskell. In Wadler [24], pp. 106–117.[20] Shelley, S. L. A Practical Guide to Stage Lighting .

Focal Press, Oxford, England, 1999.

[21] Sperber, M. Computer-Assisted Lighting Design and Control . PhD thesis, Universitat Tubingen, 2001.

[22] van Deursen, A., Klint, P., and Visser, J.

Domain-specific languages: An annotatedbibliography. SIGPLAN Notices 35 , 6 (June 2000),26–36.

[23] Wadler, P. Monads for functional programming. InAdvanced Functional Programming , vol. 925 of Lecture Notes in Computer Science . Springer-Verlag, May1995, pp. 24–52.

[24] Wadler, P., Ed. International Conference on

Functional Programming (Montreal, Canada, Sept.2000), ACM Press, New York.

Documents

Developing a Estage Lightin System