MCOBOL(ID:7005/mco004)Macro extensions to COBOLMacro extensions to COBOL, developed by the British Computer Society's COBOL Macro Working Party, and implemented by Triance at the University of Manchester Institute of Science and Technology (UMIST). Superceded by CLEF written by Yow Related languages
References: in Proceedings of Conference on European Cooperation in Informatics. Venice, 1978 view details in Proceedings of Conference on European Cooperation in Informatics. Venice, 1978 view details in Proceedings of Conference on European Cooperation in Informatics. Venice, 1978 view details in Proceedings of Conference on European Cooperation in Informatics. Venice, 1978 view details Cobo~ supported by their compiler, their normal recourse is to use preprocessors. A powerful and more flexible alternative based on a compi~erqntegrated macro facility is presented. The macro calls have the same construction rules as Cobol statements and the macroprocessor performs full validation on the calls including the arguments. The macros are written in Cobot. Such a macro facility can be used to configure users' compilers to provide the version of Cobol they require for reasons of good programming practice, efficiency, or portability. DOI Extract: Introduction Introduction The most commonly held view of a macro is of a macro call, which consists of a macro, name followed by a string of "arguments" separated by commas. This macro call is then replaced by a string of consecutive lower-level instructions. This view results from the widespread use of macros in assembler languages and to a lesser extent, in job-control languages. Since the early use of macros in assembler languages, far more sophisticated macro schemes have been devised. In 1965, Strachey published his paper on the general purpose macrogenerator (GPM) and the first paper on the less well known but more widely used TRAC was ago published. These macro schemes were followed by ML/I and Stage 2 both of which are widely used. These four are general purpose macroprocessors; the text they process is not limited to source statements of one particular language. Their importance in the context of this paper is not, however, their generality but rather the increased power and flexibility they offer the macro writer. A notable example of this is the facility within ML/I to specify macro calls with a great variety of formats, they are free format, the arguments may consist of more than one word (and may contain macro tails) and the delimiters are specified by the macro writer. For extending a particular language, however, there are significant advantages in employing a special purpose macroprocessor which can handle the source text more intelligently, and can perform much (or all) of the syntax checking automatically. The advent of high-level languages has not removed the need for macro facilities. A number of macro-based extensibility schemes for high-level languages exist. With the possible exception of the PL/I macro facility, none of them are widely used. This tack of use does not, however, imply satisfaction with the constructs provided by the languages, in the case of COBOL, there has been a delay of about a decade in the implementation of new CODASYL. facilities, and a significant portability problem results from the limited availability of some constructs, The case for the use of macros to overcome these problems is presented elsewhere. Two macro preprocessors, MetaCOBOL and Cobra, are currently used in a number of installations to enhance COBOL, The MCOBOL scheme goes further than these two in that the macro facility is designed to be part of the COBOL language, the macros are written in COBOL and the macroprocessor performs complete checking on the macro call (including the arguments), MCOBOL was designed by the British Computer Society's COBOL Macro Working Party. It has been implemented at the University of Manchester Institute of Science and Technology (UMIST) in what is believed to be the first COBOL compiler with a built-in macro facility. Extract: Objectives of the MCOBOL Design Objectives of the MCOBOL Design The various macroprocessors differ appreciably in the breadth of macro call formats, the precision with which each can be specified, and the power of macro-defining language, The design objectives of MCOBOL and the characteristics which result are now examined The main objective is to permit installations to configure their compilers to support precisely the version of COBOL that they require. In general, this involves adding some extra features. banning some features that are considered undesirable, and altering the semantics of some features that are incompatible wish the desired version of COBOL. Subsidiary objectives are: (1) In the eyes of the applications programmer, the macro calls should be indistinguishable from the base language. This means that the applications programmer should need only a manual with specifications of the enhanced version of COBOL (including macro calls} and no special knowledge about macros. {2} The macros should be portable. This means that a COBOL macro once it has been written should be usable with any compiler that supports the macro facility. (3) Writing, testing, and maintaining macro should be no more difficult than for applications programs. (4) It should be possible to control centrally within each installation the macros which are available to applications programmer. The authors believe that the first, third, and fourth objectives have been met by, MCOBOL The second objective cannot be fully met as long as Standard COBOL lacks portability, but the enhanced portability which can result from the use of macros can also be used to make the macros themselves portable (since they are written in COBOL). in [ACM] CACM 23(08) August 1980 view details in The Computer Journal 28(1) January 1985 view details |