Motivation

Before going any further, it is worth being a bit more precise about the term graphics and the use of it throughout this paper. We are concerned here with providing an appropriate programming abstraction for expressing two-dimensional graphical output in a functional language, providing a model with graphic capabilities similar to that provided by systems such as PostScriptSee section Bibliography[Adobe90] and MetaPost See section Bibliography[Hobby94]. The main goal is to provide an abstraction that is convenient and high-level enough for the programmer rather than creating a representation that could be used as a meta file picture example for drawing tools. We are not concerned with the description of 3D geometries here, and all the challenges that poses to both programmer and implementor.

What properties would we like such a two-dimensional, functional graphics model to possess?

• Pictures should be concrete. Representing a graphical object as a concrete value has its advantages. Apart from isolating and abstracting away the low-level details of a graphics system interface, having a value representing a picture allows a program to manipulate and inspect pictures to create new values. Representing a picture as a higher-order function or procedurally by a sequence of drawing actions is too opaque, as their structure cannot be unravelled by other functions, only composed together in a fixed number of ways. Instead we raise the level of abstraction and provide a declarative description of pictures, where a graphical scene is described concretely via a recursive data type that can be freely combined and manipulated by functions. The application operates in terms of the objects that they want to output and it is only at the rendering stage that the value representing the picture is actually mapped into a sequence of drawing actions.
• Simple application interface. Commonly used graphics programming interfaces have often painfully complex interfaces for accessing the graphical hardware See section Bibliography[Bartlett91]. The multitude of arguments required just to get simple graphics output from an application leads to either poorly structured programs or the avoidance of graphics completely. Simple graphics should be simple to express and integrate into an otherwise non-graphical application. Expressing graphics declaratively using a functional language focuses on the picture values that the application manipulates, shielding the programmer from having to deal with the complexities of a particular system.
• Composition. The ability to combine parts to make up a whole is a desirable feature when describing two-dimensional graphics, as scenes can often be partitioned into a clear hierarchical structure. A compositional model provides a simple way of building these scenes by repeatedly combining existing pictures to construct even `bigger' ones. The picture abstraction should also provide mechanisms for extending the range of picture combinators.
• Device independence. In the interest of portability, the graphics model should be as far as possible independent of any rendering model. The motivation for this independence is the wish to be able to provide a graphics description that could just as easily be used to provide output to a printer as to a workstation window.