One way of making protection available to the application program is through the use of a software capability that could be used as an object of computation.
Inherent in this concept is the idea that certain program components might have the privilege of creating or examining these software capabilities.
A capability-creating program would be able to execute a primitive operation that would seal a data structure, rendering the latter’s contents inaccessible to any program components that did not hold either the seal or the unseal privilege.
Such components might copy the data structure or pass its address to other program components, but they could not gain access to its contents.
The reason for introducing such software capabilities is to bring a protection mechanism into the programming language. The only problem with the concept as proposed is that the use of the seal and unseal operations takes a procedural approach to specifying protection.
A nonprocedural or declarative notation seems a preferable way to make protection available to the application programmer.
What is needed is a safe, dynamic access-control mechanism for distributing capabilities to system resources among user processes.
To contribute to the overall reliability of a system, the access-control mechanism should be safe to use.
To be useful in practice, it should also be reasonably efficient.
This requirement has led to the development of a number of language constructs that allow the programmer to declare various restrictions on the use of a specific managed resource.
(See the bibliographical notes for appropriate references.) These constructs provide mechanisms for three functions: