Design of a separable transition-diagram compiler
Communications of the ACM
A program verifier
A brief look at extension programming before and now
ACM SIGPLAN Notices
POPL '75 Proceedings of the 2nd ACM SIGACT-SIGPLAN symposium on Principles of programming languages
Further comments on "a view of coroutines"
ACM SIGPLAN Notices
| Hi-index | 0.00 |
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&equil;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.