Go backward to Architectural Specifications
Go up to CASL

Libraries of Specifications

Named specifications of various kinds can be collected in libraries.
As indicated above, CASL allows specifications to be named. An ordered collection of named specifications forms a library in CASL. Linear visibility is assumed: a specification in a library may refer only to the specifications that precede it. In fact the possibility of allowing cyclic references in CASL libraries (as in ASF+SDF) was considered, but in the presence of translation and instantiation, it seemed that the semantics would not be sufficiently straightforward.
Libraries may be located at particular sites on the Internet, and their current contents referenced by means of URL's.
Given that there will be more than one CASL library of specifications (at least one library per project, plus one or more libraries of standard CASL specifications) the issue of how to refer from one library to another arises. The standard WWW notion of a Uniform Resource Locator (URL) seems well-suited for this purpose: a library may be identified with some index file located in a particular directory at a particular site, accessible by some specified protocol (e.g., FTP).
A library may require the `down-loading' of particular named specifications from other libraries each time it is used.
Rather than allowing individual references to names throughout specifications to include the URLs of the relevant libraries (which might be inconvenient to maintain when libraries get reorganized), CASL provides a separate construct for down-loading named specifications from another library. Optionally, the specification may be given a local name different from its original name, so that one may easily avoid name clashes; the resemblance of this construct to the familiar FTP command `get' is intentional. However, a named specification at a remote library may well refer to other named specifications in that library (or in other libraries) and it would be unreasonable to require explicit mention of such auxiliary specifications, so these get down-loaded implicitly, with special local names that cannot clash with ordinary names.

The overall effect is that one may use a down-loading construct to provide access to named specifications located at remote libraries, without having to worry about anything but the names of the required specifications and the URL of the library. Notice that no construct is provided for down-loading an entire library: the names of the specifications required have to be listed. This ensures that references to names can always be checked for local declaration, before down-loading occurs.


CoFI Tentative Document: Mosses97TAPSOFT --TAPSOFT'97-- April 1997.
Comments to pdmosses@brics.dk