Interactive extensible dialect of FORTRAN 

for eXtensible forTRAN

Interactive extensible dialect of FORTRAN, which evolved over time into an interactive extensible dialect of ALGOL!

Bob Bemer IBM 1958 (extensible FORTRAN)
Green, Julien et al, Applied Programming Systems, IBM White PLains NY 1959 (Extensible ALGOL)

Influential (according to Bemer) on IAL

But obviously then became influenced by IAL and Algol 60 (which only goes to show you how family trees don't work for the history of ideas)

Related languages
XTRAN => IAL   Influence
XTRAN => Wegstein string Algol   Influence

  • Bemer, R "Techniques Department" - Translation to another language rather than compiling view details
          in [ACM] CACM 1(07) July 1958 view details
  • Bemer, R.W. "XTRAN - a compatible superstructure to FORTRAN,with growth possibilities", Proc. GUIDE, 1958 May view details
          in [ACM] CACM 1(07) July 1958 view details
  • Green, Julien; Shapiro, R. M.; Helt, F. R. Jr.; Franciotti, R. G. Theil, E. H. "Remarks on ALGOL, and symbol manipulation" view details Extract: XTRAN
    We are presently constructing an experimental ALGOL processor for the IBM 709. Our work has given rise to several considerations which we present here for those interested in ALGOL. The discussion in this paper is in three parts:
    1. External and internal representations
    2. Modifications to ALGOL
    3. Symbol manipulation additions to ALGOL

    1. External and Internal Representations
    The preliminary report on ALGOL defines the basic symbols of the language. A subset of these can be represented externally (now) only as words; e.g., go to, do, if, etc. Nevertheless, they stand for single characters which will have some internal representation. A good processor translates external representation to internal. The dictionary used in making this translation should be flexible enough to allow arbitrary changing of the external representation of an internal symbol. We can therefore say that the processing of internal symbols can be independent of the external language.1 The choice of external symbols is more important in designing a language for efficient communication between human beings than in designing the processor for that language. For can be translated as easily as vary, loop, or do.
    In any language certain symbols have syntactical meanings determined by the symbols contiguous with them. For communication between people this is practical because they can scan a group of symbols at a time. In a computer the scan is usually performed one symbol at a time and therefore all implied (syntactical) operations are converted to explicit internal symbols. This is as it should be, because the language should be designed for the convenience of the user and not the processor. (In the IBM 709 ALGOL processor this is done by a pre-scan which rearranges to remove implied syntax and redundancy.)

    2. Modifications to ALGOL
    A. if Statements
    B. Arithmetic Expressions
    C. Precedence of Operators
    D. do Statements
    3. Symbol Manipulation Additions to ALGOL
    In the development of an ALGOL processor we found it necessary to use some language to describe the functions of the processor. It seemed natural to use the string and symbol terminology of the ALGOL report in the December 1958 Communications. The translation process could then be described as a sequence of operations upon the ALGOL string of symbols that creates a new string in the object language. It was felt that if these operations were formalized into an algebra which could be added to ALGOL, the ALGOL could be used to describe its own processor. The tremendous advantage in being able to do this (aside from the obvious one of increasing the power of the language) is that it will enable us to write a crude ALGOL processor which we can use in a "bootstrap" operation to a final processor. The same technique obviously would have similar advantages for generating processors and simulators of all kinds. The practicality of implementing a symbol manipulation language was suggested by the work of Professor John McCarthy of MIT and of Newell, Shaw, and Simon of the IPL.
    Since symbol manipulation has not yet been specified in ALGOL, we have incorporated the following additions as a practical basis for producing the processor.

          in [ACM] CACM 1(07) July 1958 view details
  • Brown, James H. review of Green 1960 - XTRAN view details Extract: Review
    GREEN, JULIEN. Symbol manipulation in XTRAN. Comm. ACM 3, 4 (April 1960), 213-214.
    The symbol manipulation language incorporated in the XTRAN processor is described. The description is in the form of tables and includes the definition of a "string", string expressions, and string procedures. These functions and procedures require that symbols be treated as integers. James H. Brown, Norristown, Pa.

          in ACM Computing Reviews, January-December 1960 view details
  • Green, Julien "Symbol manipulation in XTRAN" view details Extract:
    In the September, 1959 Communications, we briefly described the symbol manipulation abilities of our processor. The following is a more complete description of the symbol manipulation language incorporated in our current processor.

    The language we are using assumes that symbols are integers (which is the case in a binary machine), and they are handled in the same fashion as integer values. This assumption was made because it provides a usable system and it seems more convenient than creating a new class of value for symbols.

    In the description the following representations are used :
    ST for a string name
    SY for a symbol name
    I for an integer name
    L for a statement label.

    1. Type Statement
    ST String (ST1, ST2, ...)--'STi' are identifiers of strings.
    A string is a sequence of symbols,

    2. String Literal
    A string may be represented in the language as follows:
    S(n,aaaa)--Identifies the 'n' symbols following the comma as a string.

    3. String Expressions (S)
    S ~ (S)
    S ~ S(n,aaa)
      ~ F( ) where F is any function defining a string vahie
      ~ ST
      ~ ST1 + ST2  Concatenate string ST1 to end of string ST2
      ~ ST1 - ST2  Remove all ST1 strings from string ST2
      ~ ST + SY Add symbol SY to end of string ST
      ~ SY + ST Add symbol SY to beginniiig of string ST
    4. String Functions
    Representation Name Class of Value Defined Description of Value
    Norm(ST) Norm I Positive integer equal to the number of symbols in the string ST
    GETNS(ST, I) Get nth symbol SY Ith symbol of string
    FIRST(ST) First symbol of string SY GETNS (ST, 1)
    SUB(ST, I1, I2) Substring ST ~ as defined in [1]
    FOS(ST, SY) First occurrence of symbol I If the symbol SY is in the string then the value defined is an integer equal to the position which the SY occupies; otherwise the value is zero.
    AI(I) Transform an integer to a string ST
    EI(ST) Transform an string to a integer ST

    5. Procedures
    Call Name Description
    FREES(ST) Free string ST := NULL STRING
    REMNS(ST, I, SY) Remove I-lh symbol Set SYequal to the I-th symbol of string ST, Remove I-th symbol of  stringST
    POINT(ST, I1, I2) Set pointer Set integer I2 to designate the I1-th symbol of string ST
    SEQ(l1, SY, 12) Sequence Set symbol SY equal to the syrnbol which I2 designates and advance I2  to the next symbol in the string If the proeedure is called after I2 has  passed the last symbol of the string transfer to statement L
    INSRT(ST, I, SY) Insert Insert the symbol SY between the Ith and the (I+1)th symbols of the  string ST so that SY becomes the (I+l)th symbol of string.
    REPLS(ST, SY1, SY2) Replace symbol with symbol Wherever the symbol SY1 occurs in string ST replace with symbol SY2  
    RPLST(ST1, SY1, ST2) Replace symbol by string Wherever replace symbol SY1 occurs in string ST1 replace by the string  ST2

          in [ACM] CACM 3(04) April 1960 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
  • Bemer, R. W. "Survey of Modern Programming Techniques," the Computer Bulletin (1961): 127-l35 view details
          in [ACM] CACM 3(04) April 1960 view details
  • Sammet, Jean E "1960 Tower of Babel" diagram on the front of CACM January 1961 view details

          in [ACM] CACM 4(01) (Jan 1961) view details
  • R. M. Shapiro "Computers, connector systems, and data descriptions" pp72-73 view details
          in Artificial languages view details
  • Sammet, Jean E., "Programming languages: history and future" view details
          in [ACM] CACM 15(06) (June 1972) view details