When specifications are collected into libraries, the question of visibility of symbols between specifications arises. In CASL, the symbols available in a specification are only those that it declares itself, together with those declared (and not hidden) in named specifications that it explicitly references. Thus when a specification in a library is changed, it is straightforward to locate other specifications that might be affected by the changes.
Another issue concerns visibility of specification names. In CASL, it is linear: a specification may only refer to names of specifications (and views) that precede it in the library. The motivation for this restriction is partly methodological (the library is presented in a bottom-up fashion), partly from implementation considerations (a library can be processed sequentially), and partly from the difficulty of giving a satisfactory formal semantics to mutually-dependent specifications.
CASL provides direct support for establishing distributed libraries on the Internet. A registered library is given a unique name, which is used to refer to it from other libraries when `downloading' particular specifications. Name servers provide the current locations of registered libraries (before a library is registered, it is referred to by its current URL). Version control is an important pragmatic concern, and the names of CASL libraries incorporate version numbers; however, it is possible to refer to a library without specifying a version (corresponding to using the largest version number that has so far been registered for the library concerned).
It may happen that the same name is used for specifications in different libraries. To avoid confusion between the names of local and downloaded specifications in libraries, a specification that is downloaded from a remote library may be given a different local name. In fact downloading bears a strong resemblance to the FTP command `get', which provides similar possibilities.