Fran (Functional Reactive Animation) is a collection of data types and functions for composing richly interactive, multimedia animations. The key ideas in Fran are its notions of behaviors and events. Behaviors are time-varying, reactive values, while events are sets of arbitrarily complex conditions, carrying possibly rich information. Most traditional values can be treated as behaviors, and when images are thus treated, they become animations. Although these notions are captured as data types rather than a programming language, we provide them with a denotational semantics, including a proper treatment of real time, to guide reasoning and implementation. A method to e#ectively and efficiently perform event detection using interval analysis is also described, which relies on the partial information structure on the domain of event times. Fran has been implemented in Hugs, yielding surprisingly good performance for an interpreter-based system. Several examples are given, including the ability to describe physical phenomena involving gravity, springs, velocity, acceleration, etc. using ordinary di#erential equations.

We have developed a simple algebraic approach to music description and composition called Haskore. In this framework, musical objects consist of primitive notions such as notes and rests, operations to transform musical objects such as transpose and tempo-scaling, and operations to combine musical objects to form more complex ones, such as concurrent and sequential composition. When these simple notions are embedded into a functional language such as Haskell, rather complex musical relationships can be expressed clearly and succinctly. Exploiting the algebraic properties of Haskore, we have furthermore defined a notion of literal performance (devoid of articulation) through which observationally equivalent musical objects can be determined. With this basis many useful properties can be proved, such as commutative, associative, and distributive properties of various operators. An algebra of music thus surfaces. 1 Introduction Traditional music notation (often called common practice no...

this paper I assume that the reader is familar with the basics of functional programming and Haskell in particular. If not, I encourage reading at least A Gentle Introduction to Haskell [HF92] before proceeding. I also assume some familiarity with equational reasoning; an excellent introductory text on this is [BW88]. 2 The Architecture of Haskore

Nyquist is an advanced functional language for sound synthesis and composition. One of the goals of Nyquist is to achieve efficiency comparable to more conventional Music N synthesis languages such as Csound (Vercoe 1986). Efficiency can be measured in space and time, and both are important: digital audio takes enormous amounts of memory, and sound synthesis programs are computationally intensive. The efficiency requirement interacts with various language features, leading to a rather elaborate representation for signals. I will show how this representation supports Nyquist semantics in a space and timeefficient manner. Among the features of the representation are incremental computation, dynamic storage allocation and reclamation, dynamic instantiation of new signals, representation of infinite sounds, and support for multi-channel, multi-sample-rate signals.

We describe a method of implementing efficient computer simulations of immune systems that have a large number of unique B and/or T cell clones. The method uses an implementation technique called lazy evaluation to create the illusion that all clones are being simulated, while only actually simulating a much smaller number of clones that can respond to the antigens in the simulation. The method is effective because only 0.001 % to 0.01 % of clones can typically be stimulated by an antigen, and because many simulations involve only a small number of distinct antigens. A lazy simulation of a realistic number of clones and 10 distinct antigens is 1,000 times faster and 10,000 times smaller than a conventional simulation—making simulations of immune systems with realistic-size repertoires computationally tractable.

ly, there is a mathematical function that maps beat numbers to time and an inverse function that maps time to beats. (Some special mathematical care must be taken to allow for music that momentarily stops, instantaneously skips ahead, or is allowed to jump backwards, but we will ignore these details.) One practical representation of the beat-to-time function is the set of times of individual beats. For example, a performer can tap beats in real time and a computer can record the time of each tap. This produces a finitely sampled representation of the continuous mapping from beats to time, which can be interpolated to obtain intermediate values. MIDI Clocks, which are transmitted at 24 clocks per quarter note, are an example of this approach. The Mockingbird score editor [Maxwell 84] interface also supported this idea. The composer would play a score, producing a piano-roll notation. Then, downbeats were indicated by clicking with a mouse at the proper locations in the piano roll score....

Nyquist is an interactive language for music composition and sound synthesis. Features of Nyquist include: (1) a full interactive environment based on Lisp, (2) no distinction between the “score ” and the “orchestra, ” (3) support for behavioral abstraction, (4) the ability to work both in terms of actual and perceptual start and stop times, and (5) a time- and memory-efficient implementation.

We begin with a functional reactive programming (FRP) model in which every program is viewed as a signal function that converts a stream of input values into a stream of output values. We observe that objects in the real world – such as a keyboard or sound card – can be thought of as signal functions as well. This leads us to a radically different approach to I/O – instead of treating real-world objects as being external to the program, we expand the sphere of influence of program execution to include them within the program. We call this virtualizing real-world objects. We explore how even virtual objects, such as GUI widgets, and non-local effects, such as are needed for debugging (using something that we call a “wormhole”) and random number generation, can be handled in the same way. Our methodology may at first seem naïve – one may ask how we prevent a virtualized device from being copied, thus potentially introducing non-determinism as one part of a program competes for the same resource as another. To solve this problem, we introduce the notion of a resource type that assures that a virtualized object is not duplicated and that I/Oandnon-localeffectsaresafe. Resourcetypesalsoprovideadeeperleveloftransparency: