REC(ID:2439/rec001)

for Regular Expression Converter.

See CONVERT.
References:
  • Tholerus, T. "REC - a recursive programming language with visible control stack, Computer Sciences Dept., Uppsala Univ., Sweden, 1975. view details
  • Sandewall, Erik "Programming in an Interactive Environment: the Lisp Experience" pp35-71 view details Extract: Introduction
    INTRODUCTION
    Why do some programming systems have to be large and complex? In recent years there has been a trend towards simple designs in computer science research. The widespread revulsion against OS/360 in the academic community led to a quest for primitive concepts in operating systems and for very simple systems, which have been successfully developed by, for example, Brinch Hansen. Similarly, reaction against large and messy programming languages encouraged the development and adoption of languages that minimized the number of facilities and features, notably PASCAL. I believe that the great attraction of very simple programming languages such as BASIC and very simple database systems such as MUMPS in the world of practical computing are other examples of the same trend towards simplicity. Despite the above, the present paper is concerned with programming systems which by necessity have to be large and complex and which are very hard to structure well because we know so little about their design. Such systems are of interest for a combination of two reasons.

    First, there is a long list of things that one wants a programming system, particularly if it is interactive, to do for the programmer. ("Programming system", is used to mean an integrated piece of software which is used to support program development, including but not restricted to a compiler.) The reader can easily generate his own list of functions, but here are some possibilities:

  • Administration of program modules and of different generations of the same module (when errors are cor- rected and/or the scope of the program is extended);

  • Administration of test examples and their correct results (including side effects), so that the relevant tests are performed automatically or semiautomatically when sections of the pro gram are changed, and a report is made to the user if a discrepancy has been observed;

  • Administration of formal and informal documentation of program segments, and automatic generation of formal documentation from programs;
  • Interdialect translation;
  • Checking of compatibility between parts of programs;
  • Translation from general-purpose or specialized higher-level languages to the chosen base language ("preprocessors"), with appropriate support for compile-time and run-time error diagnostics in the base language, com ments, etc.;
  • Support for a given programming methodology. For example, if top-down programming is to be encouraged, then it is natural to let the interactive programming system maintain successive decomposition steps, and mutual references between an abstract step and its decomposi tion;
  • Support of the interactive session. For example, a history facility allows the user to refer back to previous commands to the system, edit them, and re-execute them. An undo facility  allows the programmer to back up and undo effects of previously performed incorrect commands, thus salvaging the data-structure environment that was interactively created during the interactive debugging session;
  • Specialized editing, performed with
  • an editor that understands at least the syntax of the chosen programming language, and which therefore allows the user to refer to natural entities in this language and to give fairly high-level instructions as to where additions to the program are to be inserted;
  • Optimizing programs which transform a program into an equivalent but more efficient one; Uniform insertion programs, which in a given program systematically insert additional statements, for example for producing trace printouts or for counting how often locations in the program are visited during execution.
  • Second, and this is the crucial point, if these functions are performed by separate and independent programs, a considerable duplication of effort will result. Syntax analysis has to be performed not only by a compiler or interpreter, but also by specialized editors, optimizing programs, uniform insertion programs, documentation generators (such as cross-indexers), and so on. Analysis of the relationships between modules (calling structure, data-flow structure, etc.) is needed for generation of documentation, administration of test examples, compatibility controls, and program optimization. Since the results of an execution count may be used to tell an optimizer where it should spend its efforts, programs for these two tasks should be able to communicate. Also, some of the above facilities, such as the undo facility, are only possible if they are integrated into the programming system. For these reasons, it is natural to try to integrate facilities such as the above into one coherent programming system, which is capable of performing them all in an economic and systematic fashion.

    I believe that the development of integrated, interactive programming systems, and the methodology for such systems, is the major research issue for programming systems and programming methodology today. It is significant for programming methodology, since every detailed recommendation on how to write programs is also a recommendation on how to design an interactive programming system that supports the methodology. In the area of research on programming systems, this is relatively unexplored territory waiting to be considered now that other problems such as compiler design for conventional languages seems to be fairly well understood. The task of designing interactive programming systems is hard because there is no way to avoid complexity in such systems. Because of all the dependencies between different parts of an interactive programming system, it is hard to break up the design into distinct subproblems.

    The only applicable research method is to accumulate experience by implementing a system, synthesize the experience, think for a while, and start over.

    Such systems have been built and used for the programming language LISP. I believe that the time is now ripe for a synthesis and discussion of the experience that has accumulated in this context. The present paper is intended to serve such a purpose.
          in [ACM] ACM Computing Surveys (CSUR) 10(1) March 1978 view details