next up previous
Next: Macros Up: No Title Previous: The configuration language

Interfaces

An interface can be thought of as the type of a structure. In its basic form it is just a list of variable names, written (export name ). However, in place of a name one may write (name type), indicating the type of name's binding. Currently the type field is ignored, except that exported macros must be indicated with type :syntax.

Interfaces may be either anonymous, as in the example in the introduction, or they may be given names by a define-interface form, for example =0pt=0pt=0pt =0pt[] (define-interface foo-interface (export a c cons)) (define-structure foo foo-interface )

In principle, interfaces needn't ever be named. If an interface had to be given at the point of a structure's use as well as at the point of its definition, it would be important to name interfaces in order to avoid having to write them out twice, with risk of mismatch should the interface ever change. But they don't.

Still, there are several reasons to use define-interface:

  1. It is important to separate the interface definition from the package definitions when there are multiple distinct structures that have the same interface --- that is, multiple implementations of the same abstraction.

  2. It is conceptually cleaner, and useful for documentation purposes, to separate a module's specification (interface) from its implementation (package).

  3. My experience is that configurations that are separated into interface definitions and package definitions are easier to read; the long lists of exported bindings just get in the way most of the time.

The compound-interface operator forms an interface that is the union of two or more component interfaces. For example, =0pt=0pt=0pt =0pt[] (define-interface bar-interface (compound-interface foo-interface (export mumble)))

defines bar-interface to be foo-interface with the name mumble added.



Margaret M Fleck
Tue Nov 5 21:13:16 CST 1996