REC/SM(ID:4429/rec009)


Regular Expression Compiler/Symbolic Manipulation


Related languages
REC => REC/SM   Implementation

References:
  • Navlakha, Jainendra K. "REC/SM: a semi structured programming language" view details Abstract: Regular Expression Compiler (REC) is a programming language of extremely simple structure. It is a goto-less language which has very appealing transfer of control operations. It is a generalized language which can be implemented for special purpose applications by a proper choice of operators and predicates. This paper describes REC language and one of its "symbol manipulation" implementations, REC/SM. The language has been enormously successful from the users satisfaction point of view. And like BLISS, it has once again proved that the well-publicized inconvenience of programming without a goto is a myth. Extract: Introduction
    Introduction
    Regular Expression Compiler (REC) language is a generalized programming language which can be implemented in various specific forms as required for special purpose applications. In this paper, we informally describe REC and one of its implementations REC/SM (Symbolic Manipulation) language. REC is a goto-less language which was developed in the late sixties at MIT as part of Project MAC. That means, the language was around when the structured programming concepts were being developed. Unfortunately, it has not been reported well in the literature, and hence the computing community has essentially remained unaware of its presence. REC/SM is being used by computer programmers in various government centers, and by a large group of students in some of the major universities in Mexico for almost a decade.

    It has been noted that the formal systems of computability theory, for example, Church's Lambda Calculus, Markov Algorithms, the Post systems, etc., do not require the notion of a goto-statement. But it has been included in most of the programming languages designed from these theories mainly because it makes programming convenient, or so it seems. However, the success of languages without the goto-statement indicates that once the programmers pass a rather brief and painless adaptation period, they find that lack of goto is not a handicap.

    BLISS was one such language, and its success caused Wulf to report that "the purported inconvenience of programming without a goto is a myth". The experiences of users of REC language, and its special implementations have been similar to that of BLISS users. Because of their familiarity with languages with goto statement, there were minor problems in the adaptation period. But once they were overcome, the users discovered the scope and effect of the language on their thinking process, and found to their amazement that the quality of programs they wrote, was considerably improved. Some of the major programs developed in REC/SM are an IMLAC assembler, a plotter package, a verifier to verify information in a file, scores of systems programs, and so on. Extract: The REC Language
    REC is a programming language of simple structure, which was first developed at MIT as part of Project MAC for PDP-8, but its simple structure makes it adaptible for any digital computer. A REC-program consists of a series of RECexpressions. […]

    Parentheses denote a single REC expression, which is to be treated as one unit. Concatenation is implied by writing expression in sequence, e.g., ~8. Colon [:] implies iteration of all that part of the REC expression which precedes it. Semicolon [;] terminates the concatenation of a string. The large period [o] indicates a choice between continuing to concatenate the following expressions, or to pass over them until the next following colon or semicolon (if any) of the same parenthesis level is reached. Moreover, such a choice is always implied following every parenthesized expression. Thus, parentheses in REC expressions are used in a very technical sense, and are not meant to denote any grouping. In fact, REC parenthesization is nonassociative. Thus, REC has four control characters, ( ) : and ; McIntosh has established a i-I correspondence between a REC expression and a regular expression. This correspondence serves to demonstrate that the totality of REC expressions is no more nor less general than the totality of regular expressions. Our basic aim is to use these REC expressions to control the operation of a digital computer. Towards that end, we let the letters or symbols of the REC alphabet denote individual operations required for a specific application. A sequence of these symbols, or words of the REC alphabet, will then correspond to a sequence of operations, carried out in the order specified. Extract: Conclusions
    CONCLUSIONS:
    Knuth, in one of his famous articles says: "my dream is that by 1984 we will see a consensus developing for a really good programming language (or more likely, a coherent family of languages)." The new language UTOPIA 84 may be designed and developed in time by making use of all the available resources at hand, and perhaps some new radical ideas, too. In my opinion, the structure of REC language has much to offer in achieving such a design.

    The language has been enormously successful from the user'satisfaction point of view. And, it has once again proved the nonessentiality of a goto statement in a programming language. It is one added proof that the well publicized inconvenience of programming without a goto is a myth.

    Some of the shortcomings of the current version of REC/SM as implemented at Centro de Procesamiento, Dr. Arturo Rosenblueth in Mexico City, are discussed below. First, the current version of REC/SM tends to give rise to very cryptic programs. One possible solution is to have multiple character operators and predicates, and names of subroutines. This feature is being implemented presently. I am not very sure that this will eliminate the crytic nature of REC programs totally. Certain documentation criteria must be followed when developing REC programs. Secondly, the REC/SM compiler does not produce any cross reference listing, which makes it very difficult to debug a program. Also, the compiler messages are not accurate enough, and do not pinpoint the statement in error. However, these are implementation details which can be taken care of using existing techniques, and an attempt is being made in that direction. They do not in any way, take anything away from the language itself.
          in Proceedings of the 18th ACM Southeast Regional Conference 1980, Tallahassee, Florida view details