~41- graphical representation of such a system is shown in figure 9. The first thing to notice is that this development system is composed of two language systems, A and B hierarchically related to each other. Each level contains three domains in which typical programming activities are carried out. A general set of three such domains might be an editing domain, a debugging domain and a core transformation domain. All of the domains can be invoked in a relational manner by the development command language which thus has the utility of all the domain tools at its disposal. The core transformation domain is linked directly to other core domains by the transformation procedures of the abstract language. Thus there is a specific channel between hierarchies that simplifies the nature of the abstract languages and their implementation. In addition, domain switching between hierarchies is made more powerful by the specific transformation channels between core domains. As such, the abstract language operates only on core domain commands, further simplifying its implementation. This new refined theoretical structure while more~42- Contexts: aA DOMAIN | 1A Co oO - ] CORE DOMAIN 2a [| oO | Co T R A DOMAIN o_o N 3a J=—- 8 E a) R M jj Tr I Co o | DOMAIN N 1B Cj s oO CORE Co DOMAIN 2B oO o J DOMAIN Co 3S} PC DcL. ABSTRACT Figure 9. Theoretical structure of a meta~language based program development support environment.complicated than that originally proposed lends greater facility to potential implementation of such a program development support environment. Furthernore, the theoretical structure cogently outlines the role of meta-langauges in such development systems.-44- References: Gurel,0. "Integrated Support Environments for Hierarchical Software Development", Computer Science 91r Report, Harvard University, 1984.=45— V. IMPLEMENTATION CONSIDERATIONS OF A META-LANGUAGE BASED SOFTWARE DEVELOPMENT SUPPORT ENVIRONMENT 1. Domain Control -- Command Language The relational command system concept as manifested in the DOMAIN structure raises a number of considerations as far as the design of development command languages that support such relational command systems. While we have discussed the advantages of such relational command systems, their implementation is just as simple. Essentially, what happens is that while a development command language is running, all system commands that are accessible to the program are those exclusively within the currently operating domain. Hence, commands from other domains are not allowed and confusion between such commands is completely avoided. Each domain, in essence, creates a miniature development environment for the development control program just as when the suer is interactively working with that domain. This environment, of course, includes all the necessary commands and any contexts (including those corresponding to other domains) that-46- the programmer has attached to that domain. O£ course, commands can only be shielded between domains if it is eventually possible to access them and cross between domains. This is known as domain-switching and is an integral part of the dynamic development environment concept. As one jumps from domain to domain, they are effectively creating new environments in which they are operating in. Such domain switching commands are intrinsic to the system kernel and can also be invoked within a development control language program. These domain switching commands automatically load in specific domain environment files indicating the appropriate pending, associated and attached contexts as well as all the domain commands and their execution Procedure files. Switching out of a domain erases all of these (loading in the new ones) and updates the pending contexts and any pertinent status information which may included derivation histories. A typical development control language statement for entering a domain, in which the attached contexts are specified may be conceived as follows: ENTER domain-name (context1, context2,..., contextn) ; Extensibility of the system is also facilitated by-47- the domain concept. In this way the power and facility of the development control language may also be expanded. Since all domain interface commands are intrinsic to the system kernel, this is easy enough in that all that has to be added are the command execution files for that domain and the necessary domain environment files indicating appropriate, pending and attached and associated contexts. Since the interface between domains is very thin this can be done without changing any other components of the software development system. Furthermore, as soon as that domain is established it can be used completely by the development control language Context Control =: Abstract Language The extensibility of the abstract language is also related to the intrinsic expandability of the domain structure. Hence, extending the abstract language involves adding new core domains to the general structure. The associated programming domains for that hierarchical level are not required to extend the abstract language. However, to integrate the extension with the rest of the system the necessary program transformation procedures must be included within the abstract language. This may, in fact, prove to be48- an advantage, as the core domains (which are relatively simple to implement) may be defined and extensive research conducted on the nature of the transformation procedures. Thus, such a development support environment can be used to further research in abstract languages especially if two-way transformations can be effectuated with the help of derivation histories for all contexts. Within such a system, multiple hierarchies (as in the RPD/System) of languages can be realized and effectively integrated within the abstract language concept.~49- VI. CONCLUDING REMARKS AND FUTURE RESEARCH In this paper, we have discussed the role of meta-langauges in program development support environments. This included an analysis of development command languages and abstract specification languages. By considering these meta-languages as a unique part of the development system we were able to refine our theoretical structure for such systems and propose some implementation considerations. This structure, while considering abstractly the nature of such meta- languages, has also been refined to the extent that implementation becomes more feasible and future research stimulated. Such research might focus specifically on specialized command languages and more powerful abstract specification languages. The main impetus for such research will come form a careful consideration of the nature and integration of software development tools and the program transformation process respectively. Further work is still need in such areas as knowledge-based program development as far as it specifically relates to aspects of domain switching, abstract—50- Program transformations, and interactive program editing.DEPARTMENT OF CELLULAR AND DEVELOPMENTAL BIOLOGY HARVARD UNIVERSITY ‘The Biological Laboratories 46 Divinity Avenue Cambridge, Massachusetts 02138 GRLIAI4? 12 April 1984 Mr. Ogan Gurel Adams House I-31 Harvard University Cambridge, MA 02138 Dear Ogan: I write to confirm my offer of employment in my laboratory this summer. I understand you will be starting after your final exams end on May 29 and will continue until 10 August. You will be paid at the rate of $4.49/hour for an approximately 35-hour week. You will be assigned to work with one or more of the postdocs you spoke with during your visit and your duties will include helping with various aspects of his or her research. This will include everything from routine preparation of reagents and buffers and running of SDS-PAGE to binding studies using specific proteins and analysis of the results, depending upon your skills. I have enclosed some recent reprints on coated vesicles which you may £ind useful. I look forward to having you join us this summer. I understand you are preparing a copy of your resume for us. Daniel Branton DB/ ies Enclosures