Perlis and Smith string command language(ID:7393/per009)

Perlis and Smith at Carnegie Institute of Technology

Proposed string language, recast as a string-based Algol 58 and thence as Formula Algol

Related languages
Perlis and Smith string command language => Formula ALGOL   Evolution of
Perlis and Smith string command language => Wegstein string Algol   Incorporated some features of

  • Perlis, A. J. and Smith, J. W. "A command language for handling strings of symbols" view details Extract: Introduction
    In the past few years, a great deal of creative programming effort has been spent in the construction of automatic coding systems - "interpreters", "assemblers", "compilers". Two factors, both basic to the design and construction of such systems, have been the cause of much of the time and eIfort expended; indeed, these systems have been constructed without actually resolving these two difficulties.
    First, the only languages available for describing the efforts (and the systems themselves) are:
    a) English - a language quite acceptable to the designers, but not at all acceptable to computers; moreover a language so rich that it hides the practical techniques of detailed system construction.
    b) Machine-like languages (e. g., SOAP, SAP, Xl, GP) acceptable to the computers but so primitive that they hide the overall structure of the system. Secondly, the lack of ability to simply communicate the structure and techniques- which is implied by the first factor-itself implies that a given system can be extended for its own computer or reproduced on others only with difficulty and much duplication of effort-certainly not automatically.
    In addition to such long range programming efforts, there is an increasing number of business and data-handling problems now being solved by computer programs on a work-a-day basis. The construction of computer "solutions" to such problems is hindered by the same factor-the lack of formal describability of the processes involved. There is, of course, no lack of informal describability of the difficulty itself, to wit: " . . . I can code it, but I can not write the flow chart..."
    There exists, moreover, a host of problems whose computer solutions involve systems which have not yet been constructed- simply because the effort required is too great, i.e., economic expedience rules that their construction be deferred, perhaps indefinitely. We are here referring explicitly to at least two classes of problems:
    1) Automatic language translation, e.g.,
    a) construction of IT for the ERA 1103
    b) Russian-English translation.
    2) Formal mathematics on computers, e.g.,
    a) formal differentiation and integration
    b) formal algebraic operations and the manipulation of systems involving algebraic elements.
    The fact that all the above efforts and problems suffer from the same difficulty is mirrored in the fact that they - or the algorithms required for their solution - share several characteristics none of which are the captive of any computer:
    1) Few of the operations involved - with the exception of the basic one of counting - are explicitly numeric.
    2) The majority of the operations involve the formal and logical manipulation of symbols and of expressions made up of these symbols.
    3) Very few of the operations involved enter into the algorithms in as highly repetitive a manner as those involved in numeric problems.
    4) The systems demand the availability of, access to, and recognition of large amounts of information. Adequate computer storage is only partially a sufficient condition that these requirements be met. The essential criterion is that the "keeping track of things" be automatized; i.e., the "handling",  the storage and the retrieval of information must all be done by the system itself.
    5) The algorithms are usually imperfectly known and hence require constant modification both prior to and during execution. Clearly such modifications should be an accomplishment of the system.
    6) The problems involved in constructing a system have, in general, the same characteristics as the problems for which the system is designed; viz., business compilers, dataprocessors, et al. There appears, therefore, a clear need to construct a language and accompanying automatic programming system for problems of the kind just described.
    Such a programming system will consist of an arbitrary intermingling of interpreters and translators. Above the level of basic primitive instruction types it will be quite machine independent.
    The programming system to be defined is intended to solve, i.e., to provide the programming vehicle for, three specific problems:
    1) The language translation process-Russian into English.
    2) The construction of a flexible mathematical language compiler.
    3) The construction of a program, which we humorously entitle "2IT" , capable of constructing compilers like IT, etc.
    The language to be described below has been designed with the first three of the above characteristics in mind. It is, briefly, a command language for symbol manipulation. It is, therefore, not surprising that many of the operations of the language are similar to those developed by meta-mathematicians. All concepts in the sequel can be rigorously defined - all operations can be recursively generated from a well-defined set of primitives.

          in Preprints of papers presented at the 13th national meeting of the Association for Computing Machinery, June 11-13, 1958, Urbana, Illinois view details
  • Smith, Joseph W. "Syntactic and semantic augments to ALGOL" pp211-213 view details Abstract: The purpose of this paper is to propose a set of syntactic and semantic augments to ALGOL. The proposed extension are designed to facilitate the description of “string” manipulation in that language; they do not constitute a comprehensive language for symbol manipulation. Several such languages (LISP, IPL, …) already exist—many more will be designed and advantageously used in the future. It is felt that such languages belong in the repertoire of some language-system which contains a hierarchy of languages as well as nested “continua” of languages. In such systems, new languages may be embedded, appended, extracted at will. The fact that ALGOL is, implicitly, such a language-system seems to be only dimly recognized, even by designers. In any event, what is proposed in the sequel is not a language for symbol manipulation—qua language; but rather, a set of obvious extensions to the “algebraic-language” portion of ALGOL. To be sure, these extensions are complete in the sense that they are sufficient to describe symbol manipulations, but after all, the same statement holds for machine-language. Moreover, the extensions do not constitute a minimal set of primitives for string or symbol manipulations—in the sense that complementation, shifting, … are primitives for machine arithmetic. Such primitives are essential only to machine designers (including designers of “augmented machine”, the basic machine augmented by subroutines for arithmetics not included in the hardware); to append only such primitives to ALGOL is to visit the omissive sins of the machine designers upon the users of ALGOL. DOI
          in [ACM] CACM 3(04) April 1960 view details