Much as we try not to, we often design a new language by thinking in terms of the syntax we would like it to have. For special-purpose languages, this generally means concentrating on the syntax of the domain-specific data and operations.
In our view, thinking about the desired concrete syntax of the new language is not at all a bad place to begin the design process, as long as that step is understood in its proper relation to the overall language design. In designing FPIC, we had an existing language, PIC, to start from. We used the syntax of PIC to help answer what we consider the most crucial question in the design process: what does each piece of syntax mean? In ordinary programming terms, syntactic phrases have some intuitive operational meaning; "circle 2.0" means "draw a circle with radius 2.0." A lesson from denotational semantics is that phrases can be given precise meanings as values of well-defined sets. It is this notion of "meaning" that we found useful in designing FPIC. We wish to give the reader some idea of the thought process we went through.
We will call the set in which the meaning of "circle 2.0" resides Picture. The question is, what exactly is in this set? What is a picture? The most obvious answer is that it is some concrete representation of a picture, for example, an array of pixels or a list of drawing commands. The precise representation does not matter to us, so we will just give the representation the generic name BitMap. So, our first idea is to say
Picture = BitMap
However, a closer look at PIC tells us that this can't be quite right. In PIC, one can write, for example,
box; box
meaning to draw one box next to another. (We would write this as dbox hseq dbox.) If each box is a Picture, and a Picture is just a bitmap, then these two boxes would represent the same bitmap, which would mean precisely the same pixels drawn at the same location!
We should instead say that a Picture is the capability to draw a bitmap, given a location at which to draw it; in other words, it is a function from locations to drawing commands:
Picture = Location -> BitMap
This is close, but we have also to deal with the picture that we write (from now on, we use FPIC syntax to avoid confusion):
dbox scale 5.0
Again, the bitmap cannot be determined from the value of dbox, even after knowing its location. We might try
Picture = Location -> ScaleFactor -> BitMap
which is basically correct, but we also need to deal with color, line width, and a host of other ways in which the simple bitmap might be altered.
From this point of view, the value of dbox is just the barest indication of what will actually show up on the printed page. We represent this by defining
Picture = GraphicsContext -> BitMap
where GraphicsContext contains information about any linear transformations that may have been applied to the picture, as well as color, fill style, line width, and so on.2
We're not quite done. We know that we can refer to the points on a picture, for example dbox pt "nw". Evidently, dbox means something more than a bitmap. It means, in addition, a set of named points, which we call an Environment. This brings us to the definition we actually use in FPIC:
Picture = (GraphicsContext -> BitMap) x Environment
This definition--and it is by no means the only one possible--is the most important in the design of FPIC. Just as the domains in the denotational semantics of a language are chosen to match the properties of that language, so here the definition of Picture determines, more than any other single thing, the properties of FPIC. Indeed, once this definition is made--along with the precise definitions of GraphicsContext and Environment--the rest of the language largely falls out.
When embedding a language in a functional language like Standard ML, this type definition can also guide the implementation. Indeed, we have used exactly the type above, written in ML as
type Picture =
(GraphicsContext->BitMap) * Environment;
as the type of pictures. Many of the basic operations on pictures, and their implementations, are suggested directly by this type definition.
2. PostScript [1] has a similar notion of "graphics context."