Conversational systems programming by incremental extension of system configuration

An engineer needs tools for his trade and a laboratory or toolshop in which to store them, sharpen them, and use them. A software engineer needs programming tools and a software laboratory. Input/output routines, lexical analyzers, lexicons, storage allocators, temporary files (stacks queues, sorting files), debugging aids, etc., all are useful tools in any software factory or research house. To set up a shop one needs a program library (with librarian), a linkage convention, and a set of interface languages. In my shop (1) each program in the library must have a calling sequence; (2) the linkage convention is a peculiar coroutine linkage (with each program issuing standard subroutine calls on up to k0 virtual facilities (currently k0=8)); and (3) the interface languages are very simple and few in number. An execution instance of a program is a 'process' and may be 'active' or 'suspended'. An output stream of one process may be specified as an input stream of another.

Those who build systems such as mine (including myself) are often disinterested in providing simple but useful services like formatted output, program libraries, listing controls, etc. Furthermore we must build some facilities which are not really relevant to our goals (e.g. input-output routines, lexical analyzers, recursion mechanisms, storage allocators, syntax recognizers, and so on). If we try to use facilities constructed for other systems, we must steal copies of the source code and modify them extensively ([Ki 69]). Such facilities are almost always superfluous to our goals and should therefore be external to our systems. This externalization is surprisingly easy.