NIL(ID:1048/nil002)Network Implementation Languagefor Network Implementation Language Strom & Yemini, Watson Labs, IBM. Implementation of complex networking protocols in a modular fashion. Places
Related languages
References: in SIGPLAN Notices 18(06) June 1983 view details in Proceedings of the SIGPLAN '83 symposium on Programming language issues in software systems 1983, San Francisco view details in ACM Computing Reviews November 1984 view details NIL is a programming language and development methodology designed to support large and complex systems which are intended to be re-implemented in many product environments and which can be expected to last through several generations of hardware and several functional releases. Extract: Processes and ownership Processes and ownership A major distinguishing feature of NIL is that partitioning of the system into modules simultaneously separates the data space and the program space. A NIL system is divided into program modules calledprocesses. Every data object belongs to exactly one process. Processes may only operate on data objects which they own. All objects owned by a process are declared within the text of that process. Except for explicit communication over ports (to be discussed later), all data objects are independent in that operations on one object cannot affect any other object. The NIL view of data and processes contrasts both with conventional programming practices and with other highlevel models of processes and access control. In many system designs, collections of control blocks are connected by pointer (reference) variables. Modules are invoked with an environment containing access to certain control blocks. In general, examination of program algorithms is needed to determine which pointers are potentially used to access which other parts of the system. However, even if it is possible to determine which control blocks are accessed by a module, it is not possible to determine which control blocks may not be accessed by a suitably modified version of the module. No distinction is made between a module?s potential access and its actual access. Since in many systems there are paths from almost every control block to every other one, a change to nearly any module may entail a change to nearly any other. Various proposals exist to restrict the potential scope of access from a module to dynamic data. Data abstraction, as in SIMULA, CLU, ADA, and ADAPT, allows some or all of a control block (the private part) to be made inaccessible except within a collection of modules associated with the control block?s type. Guardians, as in Argus, are an abstraction of the notion of virtual memory spaces. Processes within a single guardian can share access to common data structures, but guardians can affect one another only via message passing. Domains, or capability lists, are used to explicitly enumerate the potential access rights of all processes being executed within the domain. In general, a single object may be simultaneously accessible from several domains. The NIL model is equally expressive, yet much simpler. Each process is conceptually a separate data space. Every object is owned by exactly one process. The set of objects owned by a process can be determined by examination of the declaration statements appearing in the process?s source text. Sharing of objects is impossible, since there are no global variables, no nested scopes, and no pointers. There is no ambiguity over which process has responsibility to initialize or finalize data, since each object has exactly one owner. Access control in NIL deals not with the right to operate on objects, but with the right to bind communications ports to form communications channels. Although NIL processes can be used to implement abstract data types, more flexible types of process interconnections are possible besides the hierarchical pattern required in the abstract data type model. In such configurations, no NIL process is more ?abstract? than any other. Extract: Dynamic configuration Dynamic configuration Ports in separate processes are connected to form communications channels. This connection must occur before communication can take place. Because we want the set of processes and the set of connections to be decided at run time, we provide run-time operations for process creation and access control, rather than requiring that the identity of the partner be specified in the program text. Connections are made in two steps: ( 1 ) The owner of an input port publishes an access right to that port into a capability object; and (2) the capability is then passed to another process which issues a connect operation that binds a specific output port to the input port designated by the capability. A process acquires its initial capabilities from its creator via initialization parameters, which are exchanged at the time of process creation. Thereafter, it may acquire and export capabilities via normal communication. The principal distinguishing features of NIL?S communication mechanism are the following: There is no communication via shared data. In that respect, NIL resembles CSP and Gypsy. Unlike the above languages, the connectiop of output port to input port is made dynamically-the sender does not have to name the identity of the receiver. Ownership transfer is sufficiently abstract that it encompasses both value copying (as in Argus?s inter-guardian communication) and reference copying. Passing an object does not entail passing other objects reachable by reference from the passed object. The caller therefore knows for certain that, on return from the call, only the passed parameters were manipulated. In other systems, a called program may correctly specify that it receives, for example, a ?Data Control Block? as parameter, and yet this does not guarantee that other structures will not be manipulated. Extract: Concluding remarks Concluding remarks The NIL language and its methodology provide a means of writing well-structured functional descriptions at a level of abstraction that permits true portability. This eliminates the intertwining of performance decisions, design, and algorithms so typical of systems that exist today. The result is a system that is easy to maintain and one that does not suffer from a gradual decay in code quality during the system life-cycle. Because NIL is an executable design language which is tunable to produce production-quality code, it becomes possible to extend the clean, modular decomposition conceived by the high-level designers directly through the functional design coding and maintenance phases. Furthermore, identical versions of the system can be made to execute on a wide variety of machines, reducing the duplication of coding effort and acceptance testing. We speculate that more uniform external specifications of products running on different machines will reduce customer migration problems and improve the marketability of upgraded hardware. Extensions to the system can be developed and sized with respect to a single common design. By contrast, within IBM at present, extensions to SNA routing function involve sizings by four separate product organizations, and extensions to session protocols may involve dozens. By rejecting at compile time programs which attempt to use unowned data or which are inconsistent with their interface, we eliminate major classes of errors before the program goes into execution, including errors which may only occur in infrequently executed program paths. Errors detected earlier are less costly to correct. Any exceptional conditions (e.g., inability to complete a dynamic binding) automatically interrupted normal control flow and invoked exception handlers. Because the system console displayed the site of the exception, it was easy for methodology and language these problems to be pinpointed during debugging. in ACM Computing Reviews November 1984 view details in SIGPLAN Notices 20(05) May 1985 view details |