JOVIAL(ID:83/jov001)

Airforce International Algebraic Language 


for Jule's Own Version of IAL.

Based on IAL (ALGOL 58), with extensions for large scale real-time programming.

Had a common shared run-time repository for all programs running on a system (the COMPOOL - for COMMunications POOL), with data elements being items, entries (records) and tables. Modes from MAD.

Extensive use by the US Air Force: most of the software for AWACS is in JOVIAL, running on IBM's AOCP (360 compatible).

Described by Barron as "being like the music of Bach - 200 years behind the times and 200 years ahead of every time" JOVIAL programs have an arcane beauty rivalled by no others. They have a forceful internal logic that transcends most other algorithmic systems.

Places
People: Hardware:
Structures:
Related languages
CLIP => JOVIAL   Evolution of
COMPOOL => JOVIAL   Incorporated features
IAL => JOVIAL   Influence
MAD => JOVIAL   Incorporated some features of
JOVIAL => Basic JOVIAL   Subset
JOVIAL => CMS-2   Influence
JOVIAL => CORAL   Influence
JOVIAL => IPLT-1   Written using
JOVIAL => JOVIAL J2   Evolution of
JOVIAL => JTS   Dialect of
JOVIAL => MPL   Influence
JOVIAL => SPL   Evolution of
JOVIAL => SYMPL   Evolution of
JOVIAL => TINT   Implementation
JOVIAL => VS BASIC   Influence

References:
  • Bockhorst, J. and Reynolds, J. "Introduction to JOVIAL Coding". SDC Report FN-L0-139 Lodi, NJ: System Development Corporation 1959 view details
  • Schwartz, J. I. "JOVIAL - Primer #1" SDC Report FN-L0-154 Lodi, NJ: System Development Corporation 1959 view details
  • Schwartz, J. I. "JOVIAL - Report #2" SDC Report FN-L0-34-1 Lodi, NJ: System Development Corporation 1959 view details
  • Schwartz, J. I. "Preliminary Report on JOVIAL". SDC Report FN-L0-34 Lodi, NJ: System Development Corporation 1959 view details
  • Bagley, Philip R. review of Schwartz, Petersen and Olson 1960 - JOVIAL view details Abstract: JOVIAL (reportedly standing for "Jules [ Schwartz' ] Own Version of I.A.L. [ now ALGOL ] ") is the language of a system for coding and checking programs for SAC's Military Computer (the AN/FSQ-31). It is based on ALGOL but has provision for detailed description and manipulation of some specific types of data.

    The major functions of the system described in this paper are:
    (1) to convert programs written in Jovial to an intermediate language,
    (2) to convert data to be used as a test environment,
    (3) to execute the program interpretively on the IBM 709,
    (4) to print out actual results and expected results side-by side.

    The purpose of the interpreter is to make possible the checkout of programs for the Military Computer before that computer actually becomes available.

    The JOVIAL system represents a workable system as advanced as the state of the art and the limitations of time and manpower admit. While it eases the task of program coding, it does not aid the even larger task of program design. The interpreter feature contributes to checkout by providing many of direct checks for coding errors and by providing for monitoring of program exeeution by snapshotting or tracing. On the other hand, JOVIAL notation contains unusual symbology because of the lack of an adequate character set. The language is billed as a "higher- level programming language& quot;, meaning that it aspires to be a language independent of any specific computer. Upon examination it is apparent that while most of the expressions in the language can be regarded as machine-independent, they are for the most part confined by the data descriptions to a limited set of techniques for carrying out operations on a specific computer. What is allowable in both the procedures and data descriptions is strongly governed by what can be executed with reasonable efficiency on a specific machine (the Military Computer).

    The paper itself was not readily understandable to this reviewer. It uses many terms not known outside of System Development Corporation.
          in ACM Computing Reviews, January-December 1960 view details
  • Schwartz, J. I. "JOVIAL - A Description of the Language" SDC Report FN-L0-34-2 Paramus, NJ: System Development Corporation 1960 view details
          in ACM Computing Reviews, January-December 1960 view details
  • Schwartz, J. I. "JOVIAL - Clarifications and Corrections for FN-L0-34-2" SDC Report FN-L0-34-2-51, Paramus, NJ: System Development Corporation 1960 view details
          in ACM Computing Reviews, January-December 1960 view details
  • Schwartz, J. I.; Petersen, K. E.; and Olson, W. J. "Jovial and its interpreter, a higher level programming language and an interpretive technique for checkout" Paper SP-165 System Development Corp., Santa Monica, Calif., 1960 view details
          in ACM Computing Reviews, January-December 1960 view details
  • Shaw, C.J. "The Compleat JOVIAL Grammar" SDC Report FN-4178, Santa Monica, CA: System Development Corporation 1960 view details
          in ACM Computing Reviews, January-December 1960 view details
  • Shaw, C.J. "The JOVIAL Lexicon: A Brief Semantic Description" SDC Report FN-4178, Santa Monica, CA: System Development Corporation 1960 view details
          in ACM Computing Reviews, January-December 1960 view details
  • Shaw, C.J. "The JOVIAL manual: Pt. 1 Computers, Programming Languages and JOVIAL" SDC Report TM-555, Santa Monica, CA: System Development Corporation 1960. view details
          in ACM Computing Reviews, January-December 1960 view details
  • Tjomsland, I.A. "The 709 JOVIAL Compool" SDC Report FN-3836, Paramus, NJ: System Development Corporation 1960. view details
          in ACM Computing Reviews, January-December 1960 view details
  • Bagley, Philip R. (Lexington, Mass.) review of Schwarz, Petersen and Olsen (1960) view details Extract: Review
    SCHWARTZ, J. I.; PETERSEN, K. E.; AND OLSON, W. J. Jovial and its interpreter, a higher level programming language and an interpretive technique for checkout. [ Paper SP-165 ] System Development Corp., Santa Monica, Calif., 1960, 39 pp.

    JOVIAL (reportedly standing for "Jules [Schwartz'] Own Version of I.A.L. [now ALGOL] ") is the language of a system for coding and checking programs for SAC's Military Computer (the AN/FSQ-31). It is based on ALGOL but has provision for detailed description and manipulation of some specific types of data. The major functions of the system described in this paper are: (1) to convert programs written in Jovial to an intermediate language, (2) to convert data to be used as a test environment, (3) to execute the program interpretively on the IBM 709, (4) to print out actual results and expected results side-by-side. The purpose of the interpreter is to make possible the checkout of programs for the Military Computer before that computer actually becomes available.

    The JOVIAL system represents a workable system as advanced as the state of the art and the limitations of time and manpower admit. While it eases the task of program coding, it does not aid the even larger task of program design. The interpreter feature contributes to checkout by providing many of direct checks for coding errors and by providing for monitoring of program exeeution by snapshotting or tracing. On the other hand, JOVIAL notation contains unusual symbology because of the lack of an adequate character set. The language is billed as a "higher- level programming language", meaning that it aspires to be a language independent of any specific computer. Upon examination it is apparent that while most of the expressions in the language can be regarded as machine-independent, they are for the most part confined by the data descriptions to a limited set of techniques for carrying out operations on a specific computer. What is allowable in both the procedures and data descriptions is strongly governed by what can be executed with reasonable efficiency on a specific machine (the Military Computer). The paper itself was not readily understandable to this reviewer. It uses many terms not known outside of System Development Corporation.

    Philip R. Bagley, Lexington, Mass.
          in ACM Computing Reviews 2(01) January-February 1961 view details
  • Bockhorst, J. "JOVIAL I/O (7090)" SDC Report FN-L0-34-3, Paramus, NJ: System Development Corporation 1961 view details
          in ACM Computing Reviews 2(01) January-February 1961 view details
  • Sassenfeld, H. W Review of Shaw 1961 Datamation 7(6) view details Abstract: The article outlines the capabilities and the structure of JOVIAL, developed and used by the System Development Corporation. The JOVIAL language is procedure-oriented, applicable to a wide range of applications, is patterned after ALGOL, and has the capability of manipulation of numeric values in both fixed and coating point, dual or complex alphanumeric values, strings of values and multidimensional arrays. Compilation is achieved in two major steps: a so-called generator takes data description statements and declarations and converts them into an Intermediate Language (IL). A translator then converts the Intermediate Language into machine instructions. The JOVIAL language and the Intermediate Language are basically machineindependent. The generator is structurally machine- independent, although it must be available in the language of the computer that executes the compiling. Machine-oriented language, which is a permissible subset of JOVIAL, and description of systems configuration are not converted into the Intermediate Language but, rather, go directly to the translator phase. The translator is machine-dependent and several translators are being written for a variety of machines, such as the 1604, 709, 7090, AN/FSQ-7, and S-2000. Two examples are given to demonstrate the appearance of the language: a matrix multiplication, and a computation of the longest run of cards in a bridge hand.
          in ACM Computing Reviews 2(01) January-February 1961 view details
  • Shaw, C. J. "Patterned after ALGOL, SDC's procedure-oriented JOVIAL" pp28-32 view details
          in Datamation 7(06) June 1961 view details
  • Shaw, C.J. "A programmer's introduction to basic JOVIAL" SDC Report TM-629, Aug. 1961 view details
          in Datamation 7(06) June 1961 view details
  • Shaw, C.J. "A programmer's look at JOVIAL, in an ALGOL perspective" pp46-50 view details Abstract: Article shows how ALGOL and JOVIAL evolved from ALGOL 58 and how they differ.
    Abstract: JOVIAL is a procedure-oriented programming language derived from ALGOL 58 [1] and designed by the System Development Corporation for programming large, computer-based command/control systems. JOVIAL is largely computer-independent; compilers for the IBM 709/7090, the CDC 1604, the PHILCO 2000, the AN/FSQ-7, and the AN/FSQ-31 are currently in operation or in checkout. These compilers fit into a variety of operating schemes that range in complexity from a compiler that operates as one task among many at the call of a complex executive system to one that sits by itself in memory and just compiles programs. This flexibility is due to the fact that JOVIAL compilers are written, in JOVIAL, in a computer-independent and, to a lesser extent, system-independent form. Extract: Alphabet and Vocabulary

    Alphabet and Vocabulary


    JOVIAL's alphabet is the FORTRAN alphabet of 48 signs consisting of 26 letters, 10 numerals, and a dozen miscellaneous marks including the blank, the prime, and the dollar sign. JOVIAL's symbols, which are delimiters, identifiers, and constants as in ALGOL, are formed of compact strings of these signs?compact in the sense of not containing arbitrary numbers of embedded blanks.


    DELIMITERS


    JOVIAL's delimiters are its verbs and punctuation and are similar to ALGOL delimiters. JOVIAL thus has its quota of separators, brackets, declarators, and arithmetic, relational, logical, and sequential operators ?and a set of file operators for describing input/output, a set of functional modifiers for manipulating machine symbols, and a set of descriptors for more elaborate data description, as well.


    IDENTIFIERS


    Identifiers are labels naming the elements of a JOVIAL program's information environment: statements; switches; procedures; items and arrays of items; tables; and files. Except for context defined statement names, all such labels must be declared, either in the program, or in a COMPOOL or system declaration list. A JOVIAL label consists of an initial letter followed by any string of letters and numerals, which may be punctuated for readability by the ' separator. Labels must therefore be two or more characters in length.


    Examples:


    U2
    STEP1
    FLIGHT?POSITION

    CONSTANTS


    JOVIAL programs manipulate four types of data: numeric data, in either floating or fixed-point representation; literal data, in either computer dependent Hollerith or standard Transmission code representation; status data; and Boolean data. Neither literal nor status values are handled by ALGOL and it is their inclusion in JOVIAL that allows it to describe its own compilation.


    Constant numeric values


    Constant numeric values may be denoted in JOVIAL by both decimal and Octal integers and by mixed decimal numbers, which may be suffixed by an Exponential scaling factor or by a (fixed-point) precision indication, giving the number of bits after the binary point.


    Examples:


    12
    0(34) .5 6.7E-8A29

    Literal values


    Literal values, which are, literally, strings of JOVIAL signs, may be denoted in either of the two possible 6-bit-per-sign encodings or directly by octal integers. Examples:



    27H(THIS IS A LITERAL CONSTANT.)
    11T(SO IS THIS.)
    O(060706103230)


    Status values


    Status values, which are qualitative or categorical in nature rather than numeric, are denoted by mnemonic names. Examples:


    V( EXCELLENT) V(READY)


    Boolean values



    And finally, Boolean values are denoted, True by 1 and False by 0.


    Extract: Comments

    Comments



    Comments, in JOVIAL, are bracketed by double prime quotes,



    "FOR EXAMPLE, THIS IS A COMMENT."


    and may be inserted, between symbols, anywhere in the program. This makes it possible to write JOVIAL in a prose style that resembles fluent, if rather spasmodic, English.


    Extract: Clauses

    Clauses



    Strings of JOVIAL symbols separated by arbitrary numbers of blanks, which may be omitted where this does not join a numeral/letter pair, form clauses: item descriptions, which describe values; variables, which designate values; and formulas, which specify values. JOVIAL, however, lacks the conditional expression of ALGOL 60, which effectively selects from a set of
    variables or formulas that one associated with the first True Boolean formula in a corresponding set of Boolean formulas.



    Item descriptions



    In JOVIAL, the basic units of data are called items. All the
    necessary characteristics of an item's value, such as its type and the format
    and coding of the machine-symbol representing it, need be supplied only once,
    in an item description. Examples:



    Floating
    fixed 10 "bits" Unsigned "integer, ranging from" 1 ... 1000
    fixed 36 "bits" Signed 15 "fraction bits"
    Rounded
    Hollerith 16 "signs"
    Status V(BAD)  V(POOR) V(FAIR)  V(GOOD) V(FINE)
    Boolean


    Literal values may be any length; however, multiple-precision fixed-point arithmetic, though intended, has not yet been
    implemented by any of the JOVIAL compilers, so that fixed-point numeric values are effectively limited :o computer word size.



    VARIABLES



    Since items are the basic units of data in JOVIAL, they are
    the principal variables. As in \LGOL, there are no limitations on the
    complexity of subscripting numeric formulas, which are enclosed in the brackets
    ($ and $).



    Examples:



    ALPHA
    BETA($T2$')
    GAMMA($0,T2+13,BETA($T2-1$)+1,99*ALPHA$)


    Although the item is normally the smallest unit of data in
    JOVIAL, it is occasionally necessary to designate a value represented by part
    of an item's machine-symbol, which may be considered a string of bits or, in
    the case of literal items, of 6-bit bytes. This function is performed by the
    subscripted functional modifiers BIT (operating on any item to designate an
    unsigned, integral value) and BYTE (operating on a literal item to designate a
    literal value.) Examples:



    BIT ($FIRST/BIT,LENGTH$) (EMPLOYEE'CODE ($EMPLOYEE/NUMBER$))
    BYTE ($9$).(MESSAGE)


    FORMULAS



    JOVIAL formulas are classified according to the type of
    value they specify?numeric, literal, status, or Boolean. Though all the
    operands in a formula must specify the same type of value, an individual
    operand may be: a constant; a variable; or a function, specifying the value
    computed by a procedure. Examples:



    1.0E-4A15
    BETA($T2$)
    ARCSIN(BETA($T2$),1.0E-4A15


    NUMERIC FORMULAS



    The syntax of numeric formulas in procedure-oriented
    languages is pretty well standardized. JOVIAL, however, is distinguished by a few
    minor differences, which bear mentioning: multiplication and exponentiation are
    signified by * and **, as in FORTRAN; absolute magnitude is signified by the
    brackets (/ and /); negation may be applied to any operand in a numeric
    formula, taking precedence over all other operations; fractional or mixed
    exponents are possible, although any exponentiation yielding a complex * root
    as undefined; there is no integer division operator, as signified by -f- in
    ALGOL 60; conversion between fixed and floating-point representation is
    automatic, where necessary. Other than these, numeric formulas in JOVIAL follow
    the standard conventions and produce the expected results, although the
    programmer is occasionally advised to keep an eye on the precision resulting
    from fixed-point arithmetic. Example:



    (27*ALPHA($0$) + (/BETA($T2$)/)** - ARCSIN(BETA($T2$),1.0E-4A15))/1.889E-6A30


    LITERAL AND STATUS FORMULAS



    Both literal and status formulas specify the value expressed
    by a single operand. Examples:



    BIT ($FIRST/BIT,LENGTH$) (EMPLOYEE'CODE ($EMPLOYEE/NUMBER$))
    BYTE ($9$).(MESSAGE)


    BOOLEAN FORMULAS



    A Boolean formula specifies True or False, computed from the
    values of its operands: Boolean constants, variables, and functions; and
    relational formulas, a further type of Boolean operand containing relational
    operators. Although relational operators signify primarily numeric relations
    (EQ, is EQual to; NQ, is uNeQual to; GR, is GReater than; LQ, is Less than or eQual
    to; LS, is LesS than; GQ, is Greater than or eQual to) they may also be used to
    compare literal and status values on .the basis of their numeric encoding.
    Unlike ALGOL, JOVIAL permits multi-relation formulas (for numeric and literal
    values), which specify True only when all the indicated relations hold. This is
    convenient for such things as determining whether a value lies within a given
    range. Examples:



    INDICATOR
    LEGAL  (SIGNAL)
    WEATHER($AIRBASE$) EQ V(FAIR)
    lT(A) LQ BYTE($COLUMN$) (MESSAGE) LQ lT(Z)


     



    The logical operators AND, OR, and NOT may be used to
    combine Boolean operands into- a complex Boolean formula. JOVIAL lacks,
    however, logical operators for implication and equivalence, as found in ALGOL:
    Example:



    INDICATOR AND NOT  (WEATHER ($AIRBASE$)  EQ V(FAIR)  OR LEGAL
    (SIGNAL))


    SENTENCES



    Delimiters and clauses combine to form statements, which
    assert actions to be performed, and declarations, which describe the
    information environment of the actions. These are the sentences of both JOVIAL
    and ALGOL. Simple JOVIAL sentences are invariably terminated by the $ separator.



    BASIC DECLARATIONS



    In JOVIAL, single values (other than those denoted by
    constants or used only as intermediate results) must be declared as items. The
    ITEM declaration corresponds to ALGOL'S type declarations but it may not be
    used, as they are, to define more than one identifier.



    A MODE declaration initiates a normal mode of item
    description for the implicit declaration of all subsequently referenced and
    otherwise undefined and unsubscripted items. ALGOL has no counterpart to this
    declaration, which JOVIAL borrowed from MAD, the University of Michigan
    Algorithm Decoder.



    Rectangular arrays of any dimension may be declared in
    JOVIAL by listing the size of each dimension after the array item name in an
    ARRAY declaration. JOVIAL's ARRAY declaration is considerably less
    sophisticated than its counterpart in ALGOL 60, which allows the programmer to
    specify a subscript range for each dimension (always 0 thru dimension-size ? 1
    in JOVIAL) in terms of numeric formulas whose values may vary at run time, thus
    implying dynamic storage allocation for arrays. Examples:



    ITEM P66 Floating $
    ITEM TALLY fixed 10 Unsigned 1..1000 $
    MODE fixed 36 Signed 15 Rounded $
    ARRAY CARD 80 Hollerith 1 $
    ARRAY TICTAC'TOE 33 Status V(EMPTY) V(NOUGHT) V(CROSS) $
    ARRAY LINE 7 5 120 Boolean $


    Named and compound statements



    Any JOVIAL statement ? simple, compound, or named ? may be
    given a name, which is separated from the statement that follows by the . separator;
    and any list of statements, which may be interspersed with declarations, can be
    grouped into a single, compound statement with the brackets BEGIN and END.
    JOVIAL lacks the "block" concept of ALGOL 60, where identifiers
    declared inside a compound statement are undefined outside it and thus may be
    used for other purposes.



    Basic statements



    The basic statements of both JOVIAL and ALGOL are similar in
    effect, but differ slightly in syntax. A JOVIAL assignment statement, however,
    cannot assign a value to more than one variable, as can an ALGOL 60 assignment
    statement, and ALGOL lacks the exchange or double assignment statement of
    JOVIAL, which is signified by the ==: separator. GOTO statements are the same
    in both, languages, but JOVIAL retains both the IF statement and the IFEITHer -
    ORIF alternative statement of ALGOL 58, which has since been replaced in ALGOL
    60 by the equivalent and more general if? then ?else conditional statement.
    Examples:



    TALLY == COUNT $
         IFEITHer TALLY GR 0 $ TALLY = TALLY*2 $
              ORIF TALLY LS 0 $ TALLY - TALLY/2 $
              ORIF 1 $ TALLY = 1 $ END
         IF 60 LQ TEMPERATURE ($AIRBASE$) LQ 90
         AND VISIBILITY ($AIRBASE$) GR 3 "miles" $
         WEATHER ($AIRBASE$) == V(FAIR) $
         GOTO PREDICT $


    FOR statements and subscripts.



    A JOVIAL FOR statement activates a subscript (which is an
    intrinsic, integer-valued variable identified by a single letter), assigns it
    an initial value, and causes the next (non-FOR) statement listed to be
    repeatedly executed one or more times. As in ALGOL, a JOVIAL FOR statement
    includes an initial-value formula, an increment formula, and a limit value
    formula but lacks the Boolean while formula of ALGOL 60 and may not include
    more than one sequence of formulas. JOVIAL is also limited since its loop
    parameter is an integer-valued variable that is undefined outside its loop,
    while an ALGOL loop parameter may be any arithmetic variable. JOVIAL has the
    advantage, however, of allowing the omission of the limit value formula in a
    FOR statement, thus creating a loop without an implicit termination test, and
    also of allowing any number of these shortened FOR statements after a complete
    FOR statement, creating a multi-parameter loop, with one controlling parameter
    and many non-controlling parameters, all of which are incremented each
    repetition. Example:



    ARRAY NODE 25 25 Floating Rounded $
              TRANSPOSE. BEGIN
                   FOR I = 0,1,24 $
                        BEGIN
                        FOR I = 0,1,24 $
                        NODE($I,J$) ==
                        NODE($J,I$)  $
                   END   END


    Table declarations.



    A table is a matrix of item values whose columns are linear
    arrays and whose rows, called entries, are therefore related sets of different
    items. Typically, entry K (NAME1 ($K$),.- - -, NAMEn($K$)) would designate
    values measuring the n pertinent attributes of "object" K. A table's
    entries all have the same composition since each consists of a similarly named
    and ordered set of items declared within the BEGIN and END brackets after the
    TABLE declaration.



    TABLE PAYROLL  Variable "length" 1000 "entries maximum" Dense "packing" $
              BEGIN
         ITEM EMP'NAME   Hollerith 18 $
         ITEM EMP'CODE   fixed 12 Unsigned $
         ITEM PAY'RATE     fixed 10 Unsigned $
         ITEM YTD'EARN    fixed 24 Unsigned $
              END


    The JOVIAL programmer also has the ability to declare: tables with entry structures like those of previously declared tables; tables with entries for which storage allocation is completely specified; and tables with entries composed of variable length item-strings, rather than single items.



    Tables are the important data structures in most JOVIAL programs, so the language provides three functional modifiers to aid their manipulation: NENT (for Number of ENTries), which allows this unsigned, integral value to be designated for Variable length tables and specified for Rigid length tables; ALL, which creates a loop to cycle through an entire table when used in an abbreviated FOR statement; and ENTRY, which allows an entry to be considered a single value, represented by a single, composite symbol. Example:



    FOR I = ALL (PAYROLL)  $
         "Eliminate empty entries?
              BEGIN  SEEK'EMPTY.
              IF ENTRY(PAY'ROLL )($!$)) EQ 0 $
                   BEGIN
                   NENT( PAY'ROLL) = NENT(PAY7 ROLL) - 1 $
              IF ENTRY (PAY'ROLL )($!$)) EQ 0 $
                   BEGIN
                   ENTRY (PAYROLL ($NENT(PAY'ROLL) $)) == ENTRY (PAYROLL.($!$)) $ GOTO SEEK'EMPTY $
         END END END


    MISCELLANEOUS DECLARATIONS AND STATEMENTS.



    The JOVIAL OVERLAY declaration names sets of items, arrays,
    and tables that must share a common memory block. Each such set thus
    "overlays" the other sets listed in the declaration. In contrast,
    ALGOL 60's own declaration lists those environment elements that must not be overlayed.



    In JOVIAL, though not in ALGOL, it is possible to declare
    items with specific initial values. For simple items, this may be done by
    inserting, into the item declaration, the descriptor Preset followed by the
    desired constant. Array and table items, however, are initialized by arrays of
    constants, listed immediately after the declaration.



    The JOVIAL DEFINE declaration establishes an equivalence
    between a label and an arbitrary string of signs by effectively causing the
    sign string to be substituted for the label wherever it may subsequently occur.
    This allows the programmer to abbreviate lengthy expressions, to make simple
    additions to the language, and to create symbolic parameters ? functions no
    "higher-level" programming language should lack, though most of them
    do.



    The JOVIAL CLOSE statement is a closed and parameterless
    subroutine removed from the normal sequence of statement executions and invoked
    only by a GOTO statement (which may be a switch call). Its normal successor is
    the statement listed after the invoking GOTO statement.



    A DIRECT statement allows the inclusion of a routine coded
    in a machine-oriented programming language. This routine, enclosed in the
    brackets DIRECT and JOVIAL, may set and use JOVIAL items.



    JOVIAL also includes: a TEST statement, which terminates the
    iteration of a loop; a RETURN statement, which terminates the execution of a
    procedure or a closed statement; and a STOP statement, which terminates the
    execution of a program. The TEST and RETURN functions are performed in ALGOL 60
    by go to statements.



    Extract: Switches

    Switches



    Two kinds of switches may be declared in JOVIAL:  indexed switches, which are similar to those in ALGOL; and item switches, which have no direct ALGOL counterpart. The numeric formula subscripting the name of an indexed switch indexes the list of statements or switch calls given in the SWITCH declaration, while the numeric formulas that may subscript the name of an item switch index the item name given in the SWITCH declaration and thus designate an item value that is -compared for equality with a list of constants, also given in the declaration, to select one from a corresponding list of statement names or switch calls. In either case, the failure of a switch to compute a statement name effectively specifies the name of the statement after the GOTO statement invoking the switch. Examples:



    GOTO STEP($K-1$)
         SWITCH STEP = (STEP1,STEP2,STEP3, , STEPS, STEP6) $
         SWITCH BRAND (WEATHER) = (V(STORMY) = MAINTAIN'SUMMARIES, V(CLOUDY) = STEP ($STATION-1$),V(SUNNY)=STEP4)  $

    Extract: Procedures

    Procedures



    A procedure, which is a self-contained computation with a fixed and ordered set of formal parameters, is invoked by a procedure statement or a function call. Calling parameters in JOVIAL are either: values, as specified by input formulas and as designated by output variables; or arrays, tables, or statements, as indicated by name. Formal parameters corresponding to calling parameter values must be declared as items within the procedure, and those corresponding to arrays and tables must be declared as such to provide the procedure with a fixed definition of their structure. The procedure itself is executed as though its formal parameters either designated calling parameter values, or were replaced with calling parameter names.


    JOVIAL uses the ALGOL 58 convention of separating input parameters from output parameters by the = separator. As in ALGOL, identifiers declared inside a JOVIAL procedure are defined for the procedure only; and for a JOVIAL procedure to specify a function value, its name, considered as the sole formal output parameter, must be declared as an item within the procedure. Although JOVIAL procedures may invoke other procedures, they may not, either directly or indirectly, invoke themselves ? as is possible with ALGOL 60 procedures. Furthermore, they lack ALGOL's complete call-by-name facility, since a parameter that is a name provides a JOVIAL procedure only with a memory address, and not a structure. Example:



    PROCedure WORDSORT  (WORD,LENGTH= ERROR)  $
         "A procedure that sorts a given length list of 5-character words into alphabetic order?
         ARRAY WORD 0 Hollerith 5 $
         ITEM LENGTH fixed 15 Unsigned $
         ITEM ERROR Boolean $
                   BEGIN
                   ERROR = LENGTH LS 2 $
                   IF ERROR $ RETURN $
              FOR I = 0,1, LENGTH - 2 $
                   BEGIN
                   IF WORD($I$) GR WORD ($1+1$) $
                        BEGIN
                        WORD($I$) == WORD ($1+1$) $
                        FOR J =I,-1 $
                             BEGIN
         IF J EQ 0 OR
              WORD($J$)  GQ WORD ($J-1$)  $
              TEST 1$
              WORD($J$) == WORD($J-1$) $
                             END    END    END   END


    Extract: Input/output and files

    Input/output and files


    To allow reasonably efficient and computer-independent description of input/output processes in JOVIAL, all data entering or leaving the computer's internal memory is organized into files. A JOVIAL file is a string of records, which are themselves strings ? of bits or of 6-bit Hollerith coded bytes. In general, records are composite symbols, which may represent entire groups of values when stored within the computer's internal memory.


    A file is activated by the execution of an OPEN INPUT or OPEN OUTPUT statement, and deactivated by a SHUT INPUT or SHUT OUTPUT statement. Active files may be both written and read, one record per transfer, although some files are read-only or write-only depending on the external storage device involved. An INPUT statement initiates a read operation, which transfers a record from the file into memory so as to represent a designated value or group of values, and an OUTPUT statement initiates a write operation, which transfers the record representing a specified value or group of values from memory out to the file. The index of the record currently available for transfer to or from the file is designated with the file-position functional modifier POSition, and ranges from 0 (indicating "rewound") thru number-of-records (indicating "end-of-file"). The transfer of a < record to or from a file automatically increments file position by one and, where the storage device allows, file position is a variable that may be altered by the assignment of an arbitrary value. The file is then called an "addressable" file, as opposed to a "serial" file where such a general positioning operation is to be avoided as impossible or inefficient.


    Files are declared either binary or Hollerith in type, and associated with each file is a set of status constants denoting the possible states of the storage device containing the file. File status may thus be determined with a relational Boolean formula wherein the file name is considered as a status variable that is automatically updated prior to comparison according to the'' current state of the file's storage device. Example:


    SORT'LEXICON'LISTS. "A routine to sort the word lists in a lexicon, using the WORDSORT procedure above." BEGIN
       FILE LEXICON Hollerith 1000." records
       Maximum?Rigid?record length of"
       500"bytes?V(INACTIVE) V(READY) V(BUSY) V(ERROR) DRUM'2000 $
       ARRAY LIST 100 Hollerith 5 $
       ITEM TROUBLE Boolean $
       OPEN INPUT LEXICON $
       READ. INPUT LEXICON LIST $
       READY. IF LEXICON EQ V(READY) $
            BEGIN
              POSition  (LEXICON)   = POSition (LEXICON) - 1 $
              WORDSORT  (LIST,100 = TROUBLE) $
              OUTPUT LEXICON LIST $
              GOTO READ $
              END
       IF LEXICON EQ V(BUSY) $
              GOTO READY $
              IF TROUBLE OR LEXICON EQ V(ERROR) $
              GOTO CORRECTION $
              SHUT OUTPUT LEXICON $
              END


    JOVIAL lacks a FORMAT declaration (as found in FORTRAN, for example) and with it the ability of most business compilers to automatically insert, in programs, input editing and report writing routines. Although this lack is JOVIAL's main weakness as a practical programming language, it can be partly remedied with library procedures.


    Extract: Programs

    Programs



    A JOVIAL program is a list of declarations and statements enclosed in the brackets START and TERM and followed by the $ separator, which indicates the typographic end of the program. The name of the first statement to be executed may be' inserted after the TERM; otherwise it is the first statement listed that is not part-of a procedure.


    Extract: Evaluation

    Evaluation



    Both JOVIAL and ALGOL, it seems, were designed by committees, but JOVIAL's poly-parentage is the more painfully apparent; it is not as "pretty" a language as ALGOL. For all its minor notational flaws, however, JOVIAL is a much more useful programming tool. It includes as much of ALGOL'S capabilities as do most ALGOL compilers (which tend to omit the hard parts) and further capabilities as well, permitting JOVIAL compilers to be written in JOVIAL. In addition, though JOVIAL can be quite cryptic in the hands of programmers uninterested in readability, it is very easy to write JOVIAL programs that can be read by non-programmers. In this respect, though no claim is made that JOVIAL programs can be written by non-programmers, JOVIAL compares favorably with COBOL. In short then, JOVIAL is probably as powerful a tool for systems programming as exists today.



          in Datamation 7(10) Oct 1961 view details
  • Shaw, C.J. "The JOVIAL manual: Pt. 1 The JOVIAL primer" SDC Report TM-555/001/00, Dec. 1961 view details
          in Datamation 7(10) Oct 1961 view details
  • Shaw, C.J. "The JOVIAL manual: Pt. 2 The JOVIAL grammar and lexicon" SDC Report TM-555/002/ 01 June 1961 view details
          in Datamation 7(10) Oct 1961 view details
  • Spierer, M. "The 7090-JOVIAL-to-7090 compiler system" SDC Report FN-LO-503, July 1961 view details
          in Datamation 7(10) Oct 1961 view details
  • Weik, Martin H. "A Third Survey of Domestic Electronic Digital Computing Systems" Rpt 1115, BRL, Maryland, 1961 view details External link: Online copy at Computer History Museum Extract: LARC details
    Univac LARC is designed for large-scale business data processing as well as scientific computing. This includes any problems requiring large amounts of input/output and extremely fast computing, such as data retrieval, linear programming, language translation, atomic codes, equipment design, largescale customer accounting and billing, etc.

        University of California
        Lawrence Radiation Laboratory
        Located at Livermore, California, system is used for the
        solution of differential equations.
    [?]
    Outstanding features are ultra high computing speeds and the input-output control completely independent of computing. Due to the Univac LARC's unusual design features, it is possible to adapt any source of input/output to the Univac LARC. It combines the advantages of Solid State components, modular construction, overlapping operations, automatic error correction and a very fast and a very large memory system.
    [?]
    Outstanding features include a two computer system (arithmetic, input-output processor); decimal fixed or floating point with provisions for double
    precision for double precision arithmetic; single bit error detection of information in transmission and arithmetic operation; and balanced ratio of high speed auxiliary storage with core storage.
    Unique system advantages include a two computer system, which allows versatility and flexibility for handling input-output equipment, and program interrupt on programmer contingency and machine error, which allows greater ease in programming.
          in Datamation 7(10) Oct 1961 view details
  • Wilkerson, M "7090 JOVIAL compiler and checker user's manual" SDC Report FN-LO-501, Apr. 1961 view details
          in Datamation 7(10) Oct 1961 view details
  • Wilkerson, M. "JOVIAL User's Manual: JOVIAL Language Specifications for 7090 and MC Compilers" SDC Report FN-L0-34-3, Paramus, NJ: System Development Corporation 1961. view details
          in Datamation 7(10) Oct 1961 view details
  • Wilkerson, M. "The JOVIAL checker, an automatic checkout system for higher level language programs" pp397-404 view details
          in [JCC 19] Proceedings of the Western Joint Computer Conference, May 1961 view details
  • Clark, E. "1604 JOVIAL compiler, program description of the translator pass 1" SDC Report TM-555/302/00, June 1962 view details
          in [JCC 19] Proceedings of the Western Joint Computer Conference, May 1961 view details
  • Clark, E. "Phase 1 of the Philco 2000 JOVIAL translator" SDC Report TM-555/211/00, Aug. 1962 view details
          in [JCC 19] Proceedings of the Western Joint Computer Conference, May 1961 view details
  • Clark, E. "Phase 2 of the Philco 2000 JOVIAL translator" SDC Report TM-555/212/00, Aug. 1962 view details
          in [JCC 19] Proceedings of the Western Joint Computer Conference, May 1961 view details
  • Dismake, N. M. review of Shaw 1961 (Datamation) view details Abstract: JOVIAL and ALGOL 60 were derived from ALGOL 58, but they have evolved divergently. ALGOL 60 includes conditional expressions, dynamic dimensioning for arrays and recursive procedures which JOVIAL and many ALGOL translators do not have. JOVIAL has the FORTRAN alphabet. In addition to delimiters similar to those of ALGOL, it has file operators for describing and using input and output files, functional modifiers for manipulating machine symbols and tables of data and descriptors for more elaborate data description. Fixed-point numbers and nonnumeric values are valid data. Several declarations, several statements, a bracket and a second kind of switch have been added to JOVIAL, which ALGOL does not include. Is it not possible to gain uniformity and a powerful tool for systems programming by taking the greater part of ALGOL and extending it in the areas which require such broadening?

          in ACM Computing Reviews 3(03) May-June 1962 view details
  • Goss, R. review of Wilkerson 1961 (WJCC paper) view details Abstract: The JOVIAL checker is a program that executes translated JOVIAL programs, which have been corrected of all errors, and selectively records test results in JOVIAL language. It occupies on the order of 16,000 cells in the IBM 7090. The paper under review is, first, an essay on the need for the Checker and, second, a description of its properties. Since at the time of publication the Checker was still in the development stage, it is hardly fair to make the review of the paper an assessment of the merits of the Checker itself, even though interesting test data on the comparison of JOVIAL and other compilers are now known.

    In attempting to justify the existence of the Checker, however, the author has allowed herself to make unwarranted generalizations. It is simply not true, and was not at the time the paper appeared, that "higher level programming languages" have not resulted in shorter and less programming training nor in faster program checkout, and that no method had been devised to produce test results from higher level language programs without the necessity of a thorough knowledge of machine language by individual programmers. Moreover, the faster coding permitted by higher level languages has in fact been reflected in vastly increased output at some computer centers. The author is entitled to report on the experience of the JOVIAL workers, but not to convey the impression that the reasons they need a Checker are of universal currency.

          in ACM Computing Reviews 3(04) July-August 1962 view details
  • Howell, H. L., Isbitz, H., and Schwartz, J . I . "Available subroutines for JOVIAL on the 7090 computer" view details
          in Howell, H. L., Isbitz, H., and Schwartz, J . I . "Documentation of the JOVIAL language and compiler for the IBM 7090 computer" SDC Report FN-6223 & supplements Jan. 1962. view details
  • Howell, H. L., Isbitz, H., and Schwartz, J . I . "Documentation of the JOVIAL language and compiler for the IBM 7090 computer" SDC Report FN-6223 & supplements Jan. 1962. view details
          in Howell, H. L., Isbitz, H., and Schwartz, J . I . "Documentation of the JOVIAL language and compiler for the IBM 7090 computer" SDC Report FN-6223 & supplements Jan. 1962. view details
  • Howell, H. L., Isbitz, H., and Schwartz, J . I . "Error messages of the 7090 JOVIAL compiler" view details
          in Howell, H. L., Isbitz, H., and Schwartz, J . I . "Documentation of the JOVIAL language and compiler for the IBM 7090 computer" SDC Report FN-6223 & supplements Jan. 1962. view details
  • Howell, H. L., Isbitz, H., and Schwartz, J . I . "Operation of the JOVIAL compiler on the 7090 computer" view details
          in Howell, H. L., Isbitz, H., and Schwartz, J . I . "Documentation of the JOVIAL language and compiler for the IBM 7090 computer" SDC Report FN-6223 & supplements Jan. 1962. view details
  • Howell, H. L., Isbitz, H., and Schwartz, J . I . "Reporting and responding to problems with the 7090 JOVIAL compiler" view details
          in Howell, H. L., Isbitz, H., and Schwartz, J . I . "Documentation of the JOVIAL language and compiler for the IBM 7090 computer" SDC Report FN-6223 & supplements Jan. 1962. view details
  • Howell, H. L., Isbitz, H., and Schwartz, J . I . "Techniques of input-output for JOVIAL on the 7090 computer" view details
          in Howell, H. L., Isbitz, H., and Schwartz, J . I . "Documentation of the JOVIAL language and compiler for the IBM 7090 computer" SDC Report FN-6223 & supplements Jan. 1962. view details
  • Howell, H. L., Isbitz, H., and Schwartz, J . I . "The communication pool for the 7090 JOVIAL compiler" view details
          in Howell, H. L., Isbitz, H., and Schwartz, J . I . "Documentation of the JOVIAL language and compiler for the IBM 7090 computer" SDC Report FN-6223 & supplements Jan. 1962. view details
  • Howell, H. L., Isbitz, H., and Schwartz, J . I . "The JOVIAL language for the 7090 computer" view details
          in Howell, H. L., Isbitz, H., and Schwartz, J . I . "Documentation of the JOVIAL language and compiler for the IBM 7090 computer" SDC Report FN-6223 & supplements Jan. 1962. view details
  • Jacoby, L. "1604 JOVIAL compiler, JOVIAL programming guide" SDC Report TM-WD-555/301/00, Oct. 1962 view details
          in Howell, H. L., Isbitz, H., and Schwartz, J . I . "Documentation of the JOVIAL language and compiler for the IBM 7090 computer" SDC Report FN-6223 & supplements Jan. 1962. view details
  • Kennedy, P. "A simplified approach to JOVIAL" SDC Report TM 780/000/00, Sept. 1962 view details
          in Howell, H. L., Isbitz, H., and Schwartz, J . I . "Documentation of the JOVIAL language and compiler for the IBM 7090 computer" SDC Report FN-6223 & supplements Jan. 1962. view details
  • Perstein, M. E,; Clark, E., and Hayes, E. "Implementation of JOVIAL in SSRL" SDC Report TM-555/200/00 Dec. 1961 view details
          in Howell, H. L., Isbitz, H., and Schwartz, J . I . "Documentation of the JOVIAL language and compiler for the IBM 7090 computer" SDC Report FN-6223 & supplements Jan. 1962. view details
  • Perstein, M. H. "JOVIAL for the dilettante" SDC Report TM- 555/061/00, Oct. 1962 view details
          in Howell, H. L., Isbitz, H., and Schwartz, J . I . "Documentation of the JOVIAL language and compiler for the IBM 7090 computer" SDC Report FN-6223 & supplements Jan. 1962. view details
  • Rizzo, M. "Critique of the JOVIAL User's Manual FN-L0-34-3", SDC (internal use only) Report N-L0-2109/000/00 Paramus, NJ: System Development Corporation 1962 view details
          in Howell, H. L., Isbitz, H., and Schwartz, J . I . "Documentation of the JOVIAL language and compiler for the IBM 7090 computer" SDC Report FN-6223 & supplements Jan. 1962. view details
  • Roam, R. F. review of Shaw, C.J. SDC Report TM-555 view details Abstract: JOVIAL is a language derived from ALGOL 58 primarily for use in programming military command systems. It features data-description capability, data packing facilities, and the capacity to express manipulation of non-numeric information. In spite of its rather specialized intent, it is in reality a powerful general purpose language. JOVIAL processors exist for, or are being coded for, the IBM 709/90, the CDC 1604, the Philco 2000, the AN/FSQ-31 and the AN/FSQ-7.

    The programmer's introduction is a slightly watered-down version intended to get the user to write an efficient program while not overwhelming him with all the features of the language. It takes on somewhat the same role as the FORTRAN primer. The syntactical rules are conveyed in a modified Backus normal form, and perhaps the actual Backus notation itself might have been used in order to alleviate confusion should the reader happen to be involved in an ALGOL 60 effort at a later date. The author states that the alphabet for JOVIAL statements consists of essentially the characters on the IBM FORTRAN keypunch with the edition of the apostrophe. He then proceeds to use these as well as the lower-case letters in his formal syntactical exposition. The use of the additional twenty-six characters was found to be confusing. The second volume of the JOVIAL Manual is subtitled "The JOVIAL Grammar and Lexicon." It is designed as a reference for those who already have had experience with the language. The syntax and semantics are interleaved. The syntax is defined in terms of operators designating concatenation, selection, single forms, strings of forms, etc. There is an extensive section devoted to data descriptions.

    It is a matter of taste as to whether this manual is of great use. Those more used to a less formal but equally complete presentation such as in the MAD Manual (University of Michigan) find the notation used in this work cumbersome. It is likely that persons used to the JOVIAL Manual would find the MAD Manual disturbing in its lack of formality. The reviewer would welcome a chance to see parts 1, 3 and 4 of the Manual which are entitled: "Computers, Programming Languages and JOVIAL" "The JOVIAL Primer" "Supplement to the JOVIAL Manual" Although this manual has no index, it has a detailed table of contents.
          in ACM Computing Reviews 3(01) March-April 1962 view details
  • Schwartz, J. I. "JOVIAL: A General Algorithmic Language" pp481-493 view details
          in Symbolic Languages in Data Processing, in the Proceedings of the Symposium organized and edited by the International Computation Centre, Rome, Italy, March 26­31, 1962, Gordon and Beech Science Publishers, 1962. view details
  • Steel, T. B. Jr. "Languages and real time information processing" view details
          in Automatic programming and compilers III view details
  • Shaw Christopher J. "A specification of JOVIAL" view details
          in [ACM] CACM 6(12) (Dec 1963) view details
  • Shaw, Christopher J. "Jovial and its documentation" view details
          in [ACM] CACM 6(03) (Mar 1963) view details
  • Shaw, Christopher J. "Jovial. A Programming Language For Real-Time Command Systems" pp53-120 view details
          in Goodman, Richard (ed) "Annual Review in Automatic Programming" (3) 1963 Pergamon Press, Oxford view details
  • Bachelor, C. A. review of Shaw 1963 view details Abstract: This report is evidently an improved version of an SDC Technical Memorandum, [ TM-629, "A Programmer's Introduction to Basic Jovial", Aug. 7, 1961 ] by the same author. The first paragraph describes its purpose quite well:

    "This report gives a complete specification of the latest official version of JOVIAL, a general-purpose, procedureoriented, and largely computer-independent programming language developed by System Development Corporation for large-scale military systems and as a corporate standard."

    According to a footnote, the JOVIAL language described in this article had been unchanged since June, 1961, but some minor improvements and extensions were being considered and would probably have been adopted by the time the report was published.

    JOVIAL is derived from ALGOL 58 and CLIP, and includes provisions for handling floating point and fixed point numbers, Boolean values, and literal and "status" quantities. It also includes provision for organizing data items into tables. At the time this report was written, there was no compiler that would handle all of the features of JOVIAL, but every feature had been implemented in at least one compiler. SAC has "built" JOVIAL compilers for several computers, including the IBM 7090, the AN/FSQ-31v, the AN/FSQ-32, the AN/FSQ-7, the Philco 2000, and the CDC 1604 and 1604A. JOVIAL compilers have been received by some 30 computer installations outside SDC.

    This report gives a specification of JOVIAL in a manner similar to that of the ALGOL report [ "Revised report on ALGOL 60." Comm. ACM, 5, (Jan. 1963) ] . That is, the syntax of JOVIAL is defined by a metalanguage similar to the Backus Normal Form, and English language is used to describe the meaning (semantics) of the constructions defined by the syntactic rules.

    It should be noted carefully that the metalanguage used here is a modified form of Backus notation. The ( and ) brackets are used for grouping, and metalingmstic variables are simply strings of lower case letters, possibly hyphenated. JOVIAL uses "blank" or "space" as a separator, and this is signified in the syntactic formulas by the symbol ~ . The syntax also includes semantic "cues", in the form of subscripts consisting of strings of letters or words. This makes the syntactic rules more readable.

    Naturally, a report of this nature is not exactly easy to read. Two aspects which tend to increase the difficulty are, first, the fact that JOVIAL is a rather complicated language; and, second, the somewhat unusual terminology employed. Some examples of the latter are: "sign" means "basic character"; "numeral" is the name for "digit"; and "numeric- formula" means "arithmetic expression".

    The syntactic rule for "numeric-formula" permits any number of unary plus or minus signs to precede an operand; for example, + - +BETA would be a valid expression. I'm not sure whether this is intentional, or a mistake. A similar situation occurs in the use of NOT in a Boolean-formula.

    In some places, the semantics are not very clear. This is especially true in the description of loop statements (these correspond roughly to for statements in ALGOL). Perhaps some of the difficulty is that, in order to understand one feature, it is necessary to understand an associated feature, and vice-versa. Thus a second reading of the report should make things more understandable.

    These criticisms are relatively minor, however. In general, the report is very well written, and remarkably free from errors. It should be of considerable use to anyone who is interested in an accurate description of JOVIAL.

          in ACM Computing Reviews 5(05) September-October 1964 view details
  • Leavenworth, B. Review of Shaw 1963 (JOVIAL) view details Abstract: JOVIAL is described as a general-purpose, procedure-oriented and largely computer-independent programming language (the author should be congratulated for his avoidance of the terms " problemoriented" and "machine-independent" which are used freely in the literature). JOVIAL compilers are written and maintained almost entirely in JOVIAL but the listings are not included in the documentation. A primer, and a formal description of the language containing syntactic definitions are available. However each compiler for a particular machine may process a separate dialect of JOVIAL SO that local ground rules are required.

    The author seems to feel that informal descriptions are more suitable for programmers (users) whereas formal, syntactic descriptions should be used as a communication device from language designers to language implementors (compiler writers).

    It is interesting to note that manuals have by this time been produced for two other types, the trainee programmer, and the dilettante programmer (the part-time non-professional programmer).

    A selected bibliography of JOVIAL documents is given.

          in ACM Computing Reviews 5(01) January-February 1964 view details
  • Marsh, D. G. "Jovial In Class" pp167-182 view details
          in Goodman, Richard (ed) "Annual Review in Automatic Programming" (4) 1964 Pergamon Press, Oxford view details
  • Rosen, Saul "Programming Systems and Languages: a historical Survey" (reprinted in Rosen, Saul (ed) Programming Systems & Languages. McGraw Hill, New York, 1967) view details
          in [AFIPS JCC 25] Proceedings of the 1964 Spring Joint Computer Conference SJCC 1964 view details
  • Rosen, Saul Review of Shaw 1963 ARIAP p87 view details Abstract: An expert in computer languages must know FORTRAN, ALGOL and COBOL. He should also have some knowledge of other important computer languages, and JOVIAL must be included in this category. It is very widely used in military systems work, and JOVIAL compilers exist for many different computers.

    JOVIAL is probably the best documented of all computer languages. Most of the credit for this goes to the author of this paper. In particular his Jovial Primer is an excellent description of the language with many examples and illustrations. [ It was published as Systems Development Corporation TM-555/ 003/00, and is Part 3 of the Jovial Manual. ]

    The current article makes a slight condensation of the Jovial Primer available to a wider audience. A brief introduction has been added, and, unfortunately, all illustrations have been removed. Another and perhaps more serious deletion is the table of contents, which would be very useful in an article this long. This paper should prove to be interesting and useful to those who do not have access to the Primer.

    The JOVIAL language is derived from ALGOL 58. It added to the basic algebraic language an extensive vocabulary for defining data items of various kinds and for defining and using elaborate tables consisting of such items. The use of such tables is perhaps the most characteristic feature of JOVIAL.

    A number of clumsy features were put into the language at the beginning and have apparently been frozen into its specifications. Thus, single letter names are reserved for controlled integer valued variables in for statements, and may not be used for real variables. One may refer to the real variable XX, but not to a real variable X. Also, the test for completion of a loop is made at the end of the loop. ALGOL makes its tests at the beginning and this is usually considered to be an improvement over FORTRAN which placed its tests at the end.

    In the opinion of this reviewer, much important information in the computer field is accessible only in manuals and documents that are not normally distributed.to the general public. I therefore welcome the publication of this very fine description of JOVIAL. Saul Rosen, Lafayette, Ind.

          in ACM Computing Reviews 5(02) March-April 1964 view details
  • Schwartz, Jules I.; Coleman, Edward G.; and Weissman, Clark "A general-purpose time-sharing system" pp397-411 view details Extract: Time-Sharing Applications
    Time-Sharing Applications
    To illustrate the "general purpose" nature of the Time-Sharing System, we focus on two interesting programming systems currently operating on TSS as service systems for the user. The first, IPL-TS, is a complete list-processing system for the Information Processing Language V developed by Newell, Simon, and Shaw. The second, TINT, is an on-line Teletype INTerpreter for the JOVIAL algebraic language developed by SDC. When the Time-Sharing System is equipped with these two programming-language systems, the user is immediately provided with a familiar programming system to ease his transition to programming for time-sharing, and allowed to use, with little or no modification, any code he may have previously written in IPL-V or JOVIAL for other machine systems. Extract: On-Line Program Composition
    On-Line Program Composition
    Both IPL-TS and TINT allow the user to write symbolic programs on-line and to execute them immediately, by themselves or in conjunction with previously coded routines. With IPL-TS, the programmer uses the special system routine, Linear IPL (LIPL),* which accepts IPL code on-line in a symbolic, linear, parenthesis format convenient for keyboard input. Figure 6 presents an example of LIPL being used to compose and execute Ackermann's function on-line. TINT, which was developed specifically for on-line program composition, accepts JOVIAL statements on-line in the same linear format used for compiler input.
    The ability to program on-line frees the programmer from having to concern himself with all the formalities of punched card accounting. With experience and facility, he programs online directly from his thoughts or, for more difficult problems, directly from a flow diagram, circumventing such time-consuming tasks as program-coding-sheet preparation, key punching, card sorting, editing, and prestoring. The time saved by the programmer can be applied to other coding tasks or to quality review of his current code.
    No programmer, of course, could compose a large program at one sitting with either of these systems, but this is a human, not a system, limitation; LIPL has no upper bound, and TINT'S 600-statement limit effectively exceeds a human's short-term comprehension. Optimally, these systems should be used for programs that can be written and debugged m one or two sittings (usually under 100 IPL instructions or 50 JOVIAL statements).
    There are three immediate consequences of this practical size limitation. First, many non-trivial, one-shot programs, such as for statistical computations, can be coded, debugged, and executed at one sitting. Often a programmer himself will refrain from writing such programs, knowing the time and effort involved. Figure 7 shows the Teletype communication resulting from an exercise using TINT as a "desk calculator" for computing the standard deviation of a set of research data. Second, large programs take on a modular structure; that is, large programs become a concatenation of numerous smaller programs and subroutines. Third, programmers begin to amass personal libraries of short utility subroutines, which they use to build larger programs. Clearly, consequences two and three would not exist, except in trivial cases, if it were not possible to work one day with code developed en prior days. Both IPL-TS and TINT provide this capability.
    TINT may accept symbolic input from magnetic tape, and can integrate this input with on-line Teletype input when so directed by the user. Thus the results of one day's coding can be filed on tape for later use. An alternative, if the symbolic JOVIAL statements have been executed and debugged, is to compile the code and save the binary output on a binary library tape, thus, again, integrating previous work with current code; however, the binary library approach has greatest value when used for utility routines.
    IPL-V is essentially a language of subroutines (composed from an inventory of some 200 system subroutines called J routines or primitives). Programs written in IPL-V are usually modular hierarchies of subroutines. Therefore, on-line composition of IPL-V programs is a natural extension of the language, and many alternatives for continuity of programming across many days of operation already exist within the language. For example, the programmer may "fire" a J166 (Save For Restart) at any time and continue from that point at a later date, or he may load a program from symbolic tape using the loader or J165 (Load Routines and Data) and continue using LIPL on-line.
    Therefore, the attributes of IPL-TS and TINT, when combined with a programmer's imagination and skill during on-line program composition, reduce significantly the tedious, uncreative tasks of code preparation and increase productivity. This point is particularly apparent to all programmers who have been required to debug code that they wrote several days earlier, and that has grown "stale" while it was being keypunched, compiled, and executed. Instead of expending additional time and energy becoming reacquainted with his code before he can correct his errors, the programmer can, by composing the code on-line and executing it immediately, debug while the code is still fresh in his mind.


    * LIPL was designed and coded by R. Dupchak while cons'iltant to the RAND Corporation, Santa Monica
    Extract: On-Line Program Debugging
    On-Line Program Debugging
    The particular ability of IPL-TS and TINT to detect, locate, and correct program errors online is perhaps their greatest asset, since it leads to substantial decrease in program turnaround time. In effect, IPL-TS and TINT increase the programmer's debugging efficiency by allowing him to check out more code per day than would be possible with non-time-sharing operation.
    Extract: Error Detection
    Error Detection is the first step in debugging any program. Errors may be classed as either grammatical errors in language or format, or logical errors in code execution. The generator screens out most grammatical errors for TINT, and either the loader or LIPL performs the same task for IPL-TS. Logical-error detection, however, is a more difficult task, even with IPL-TS and TINT. The advantage of these systems for error detection is their responsiveness to the programmer. He may choose to develop on-line, special-purpose debugging tools to suit his individual preference, or he may use those debugging tools provided by the system. For example, IPL-TS currently provides an error trap for some twenty illegal IPL operations resulting from faulty program logic; when such errors occur, IPL-TS attempts to provide the programmer with as much information as possible to help him correct his error. First, an error message is sent to the programmer to inform him of the error's occurrence and of its nature. Second, a special system routine, Trace Dump (discussed below), provides him with a "back trace" of the code leading up to the error to help him locate the cause of the error. Finally, the system pauses at a breakpoint, to allow him time to correct the error. However, all three steps may be altered, since the IPL-TS error trap mechanism is designed with a "thin skin" to allow the programmer to substitute his own trapping action in lieu of that provided by the system.
    With TINT, logical-error detection is left more to the imagination of the programmer. TINT allows the programmer to insert a PRINT statement, with numerous item names as arguments, at any point in his program. When it encounters this statement during program execution, TINT responds by printing on the user's Teletype the current values of all specified items. In this fashion, the programmer may take item snapshots at critical points in his program The power of the PRINT statement for logical-error detection is amplified when combined with the TINT READ statement The READ statement is the converse of the PRINT statement When TINT encounters this statement during program execution, the programmer must insert the current values of prespecified items By judicious use of the READ and PRINT statements, the programmer can repeatedly exercise a program with different initial conditions and review his results with input/output transfer-function analysis
    Thus, on-line user program communication increases a programmer s debugging efficiency by increasing his ability to detect program errors It is typical for a programmer, checking out new code with IPL-TS or TINT, to detect and correct half a dozen program errors in the first hour of operation, such error correction might easily have required a week with conventional programming systems Extract: Error location
    Error location
    The pinpointing of the erroneous code is often considered no different from error detection This may be true for grammatical errors but is far from true for logical errors The knowledge that an error exists does not, in and of itself, narrow the search for the error's location The user of IPL TS, there fore, is provided with a description of the system detected error and the aforementioned back trace of the code leading up to the error Back tracing by the system is performed in the debugging mode by the special system routine Trace Dump, which prints a full trace of up to the last 100 interpretation cycles, in reverse order (last cycle first) The number of previous cycles printed is controllable on-line Experience shows that the location of an error can usually be found within the first five cycles printed and that it is rarely necessary to go deeper than ten cycles back For logical errors not detected by the system the programmer has available all the standard IPL-V Monitor Point functions, m addition IPL TS extends these functions to include breakpoint operation as a programmer initiated option The option may be invoked at load time or during program execution In addition, the IPL primitive J7 (Halt) has been implemented as an alternative breakpoint mechanism When a breakpoint is encountered by IPL-TS, the programmer is notified and requested to enter the name of any regionally denned routine, which is then executed immediately Upon completion of the routine, the programmer is again queried He may continue to fire routines at the breakpoint or he may exit back to the prior program, the context of which has remained undisturbed.
    Breakpoints are not a panacea for locating erroneous code, however, they do provide additional control flexibility at critical points in a program In fact, the user of TINT must lelj almost exclusively on breakpoint logic for locating erroneous code the aforementioned READ and PRINT statements are in effect breakpoint statements For elusive errors these statements may be used to bracket groups of JOVIAL statements, and in extreme cases, individual JOVIAL statements TINT also provides a STOP statement, which is also a breakpoint statement When the interpreter encounters the STOP statement, the program is suspended until directed by the user to continue The user may also reexecute his program from a STOP breakpoint, or he may enter new code or edit prior code before continuing TINT'S STOP statement is analogous to the IPL-TS J7 (Halt) primitive.
    Extract: Error correction
    Error correction in symbolic code with either IPL TS or TINT is essentially on line program composition LIPL allows the IPL programmer to erase, extend, or modify selectively any user routine existing in the system TINT, similarly, allows the programmer to edit any JOVIAL code written, on a statement-by-statement basis
    Here, again, the programmer's control over his program is effectively increased He can correct code in several minutes instead of the several days typical with most computer installations

          in [AFIPS JCC 25] Proceedings of the 1964 Spring Joint Computer Conference SJCC 1964 view details
  • Shaw, C. J. "A comparative evaluation of JOVIAL and FORTRAN IV" Automatic Programming Inf., No. 22. Technical College, Brighton, England, Aug. 1964, 15 pp. CR-6562-7265. view details Abstract: A descriptive point-by-point comparison of these two languages. Concerned mainly with the features of the languages rather than their processors
          in [AFIPS JCC 25] Proceedings of the 1964 Spring Joint Computer Conference SJCC 1964 view details
  • Weik, Martin H. "A Fourth Survey of Domestic Electronic Digital Computing Systems" Report No. 1227, January 1964 Ballistic Research Laboratories, Aberdeen Proving Ground, Maryland view details External link: Online copy at Computer History Museum
          in [AFIPS JCC 25] Proceedings of the 1964 Spring Joint Computer Conference SJCC 1964 view details
  • Goldstein, M. "Computer Languages" The American Mathematical Monthly, Vol. 72, No. 2, Part 2: Computers and Computing Feb., 1965 pp141-146 view details Extract: Languages scene
    An important step in artificial language development centered around the
    idea that i t is desirable to be able to exchange computer programs between
    different computer labs or at least between programmers on a universal level.
    In 1958, after much work, a committee representing an active European computer
    organization, GAMM, and a United States computer organization, ACNI,
    published a report (updated two years later) on an algebraic language called
    ALGOL. The language was designed to be a vehicle for expressing the processes
    of scientific and engineering calculations of numerical analysis. Equal stress was
    placed on man-to-man and man-to-machine communication. It attempts to
    specify a language which included those features of algebraic languages on
    which it was reasonable to expect a wide range of agreement, and to obtain a
    language that is technically sound. In this respect, ALGOL Set an important
    precedent in language definition by presenting a rigorous definition of its syntax.
    ALGOL compilers have also been written for many different computers.
    It is very popular among university and mathematically oriented computer
    people especially in Western Europe. For some time in the United States, it will
    remain second to FORTRAN, with FORTRAN becoming more and more like
    ALGOL.
    The largest user of data-processing equipment is the United States Government.
    Prodded in Part by a recognition of the tremendous programming investment
    and in part by the suggestion that a common language would result only
    if an active Sponsor supported it, the Defense Department brought together
    representatives of the major manufacturers and Users of data-processing equipment
    to discuss the problems associated with the lack of standard programming
    languages in the data processing area. This was the start of the conference on
    Data Systems Languages that went on to produce COBOL, the common business-
    oriented language. COBOL is a subset of normal English suitable for expressing
    the solution to business data processing problems. The language is
    now implemented in various forms on every commercial computer.
    In addition to popular languages like FORTRAN and ALGOL, we have
    some languages used perhaps by only one computing group such as FLOCO,
    IVY, MADCAP and COLASL; languages intended for student problems, a
    sophisticated one like MAD, others like BALGOL, CORC, PUFFT and various
    versions of university implemented ALGOL compilers; business languages in addition
    to COBOL like FACT, COMTRAN and UNICODE; assembly (machine)
    languages for every computer such as FAP, TAC, USE, COMPASS; languages to simplify problem solving in "artificial intelligence," such as the so-called list
    processing languages IPL V, LISP 1.5, SLIP and a more recent one NU SPEAK;
    string manipulation languages to simplify the manipulation of symbols rather
    than numeric data like COMIT, SHADOW and SNOBOL; languages for
    command and control problems like JOVIAL and NELIAC; languages to simplify
    doing symbolic algebra by computer such as ALPAK and FORMAC;
    a proposed new programming language tentatively titled NPL; and many,
    many, more. A veritable tower of BABEL!
          in [AFIPS JCC 25] Proceedings of the 1964 Spring Joint Computer Conference SJCC 1964 view details
  • Ingerman, Peter Z. review of Marsh 1964 (Jovial) view details Abstract: This paper describes the philosophy of design of a computerbased automated instruction scheme for teaching Jules' Own Version of the International Algebraic Language (JOVIAL) in SDC's Computerized Laboratory for Automated School Systems (CLASS). (The title of the article was generated by a full-time acronymist.)

    Except for a few astonishing lapses, this is a well-written but overbrief paper, and an expanded and more detailed version rould be welcome. The most noteworthy lapse (to this reviewer) may be a criticism of the teaching profession, rather than of the paper: it is asserted that "In automated instrucbon, the human instructor takes on different functions than in an ordinary classroom." This is inarguable. The statement is followed by: "His new functions may include monitoring the student's progress and providing individual help when needed." Hopefully, only the methods used to censor and succor have changed, but not the acts!

          in ACM Computing Reviews 6(04) July-August 1965 view details
  • Sammet, Jean E., "Roster of Programming Languages 1967" view details
          in Computers & Automation 16(6) June 1967 view details
  • Feldman, Jerome and Gries, David "Translator writing systems" p77-113 view details Abstract: A critical review of recent efforts to automate the writing of translators of programming languages is presented. The formal study of syntax and its application to translator writing are discussed in Section II. Various approaches to automating the postsyntactic (semantic) aspects of translator writing are discussed in Section III, and several related topics in Section IV. Extract: Extendible Compilers -- Basic Concepts
    Extendible Compilers -- Basic Concepts
    Many attempts (starting with McIlroy [McI1 60]) have been made to embed macro features in compiler systems. One approach was to retain the macro syntax form but add a number of built-in features which are compiler-like. The SET system [Ben 64a] included a skeleton compiler with input-output, symbol manipulation, table handling, and list processing features. These built-in routines were combined with translation time operations (action operators) in the attempt to build a TWS. A more successful approach has been to use the structured syntax of high level languages as a basis for extension.
    Many existing compilers (including PL/I [IBM 66]) incorporate simple forms of macro expansion, the first probably being JOVIAL [Shaw 63]. The most primitive form is pure text replacement without parameter substitution.
    For example, in B5500 ALGOL one could define a macro with the statement:
    DEFINE LOOP 1 = FOR I ~ 1 STEP 1 UNTIL N
    and later write statements like
    LOOP 1 N DO A[I] ~ 0
    which would be expanded into
    FOR I ~-- 1 STEP 1 UNTIL N DO A [I] ~-- 0.
    The next step is to allow a macro definition with parameters.
    This facility has been included in the AED-0 compiler [Ross 66], among others. In AED-0 one might define a macro with the statement:
    DEFINE MACRO LOOP (P1, P2) TOBE
    FOR P1 ~-- 1 STEP 1 UNTIL P2 DO ENDMACRO.
    In this case, one could get the same result as above with the shorter statement
    LOOP(I, N) A[I] ~-- O.
    These two simple macro forms would form a useful addition to any high level language, and one might imagine developing mechanisms which parallel more sophisticated macro techniques. Although AED-0 does permit arbitrary strings as parameters, and nested definitions, features like conditional assembly do not seem to have been widely used in high level languages. One reason for this is that compilers normally depend heavily on the structure of the text; the next two sections describe the complexities that arise in trying to extend compilers with macro techniques.
          in [ACM] CACM 11(02) (February 1968) view details
  • Perstein, M.H. "Grammar and Lexicon for Basic JOVIAL" SDC Report TM-555/05/01A, Santa Monica, CA: System Development Corporation 1968 view details
          in [ACM] CACM 11(02) (February 1968) view details
  • Sammet, Jean E. "Computer Languages - Principles and History" Englewood Cliffs, N.J. Prentice-Hall 1969. view details Extract: Development of JOVIAL
    In June, 1958, the System Development Corporation initiated a research project to investigate the problems of automatic coding. This project resulted in the development of CLIP (Compiler Language for Information Processing). Much of this work was similar in spirit to that being done for IAL (i.e., ALGOL 58); the specifications for IAL were published in December, 1958, and SDC adopted the notation of IAL but made certain additions and modifications to permit greater convenience in expressing data manipulations, Certain other facilities were omitted. Thus, CLIP was really a derivative of ALGOL 58. (A further discussion of CLIP, including some of the statements about its initial purpose and the list of references, is in Section IX.2.5.2.) Early in 1959, SDC's SACCS (Strategic Air Command Control System) Division in New Jersey decided to develop a similar language (eventually called JOVIAL) that would be useful for programming SACCS. Since CLIP was a research effort involving compiler writing and was being developed 3000 miles away, it was not possible to keep the languages the same. Whether right or not, JOVIAL has survived as the major SDC language.
    SDC actually began work on JOVIAL in February, 1959. A year later, a JOVIAL interpreter was running on the 709, and by December, 1960 a compiler for the 709 was running on the 709. {1} The story of the name JOVIAL has been told many times in differing versions. According to the man who should know, namely Jules Schwartz, the key points are as follows: He wrote a draft proposal for a programming language to be used for the Air Force 465L program. The language was based on IAL, but it had additional facilities. The title he put on the draft was OVIAL (Our Version of the International Algebraic Language). The language concept was accepted, but the word JOVIAL was not considered satisfactory for several reasons. A suggestion for a new name was JOVIAL, and this was accepted. However, it was necessary to decide what JOVIAL stood for, and one joking suggestion was that it should be Jules' Own Version of the International Algebraic Language. According to Schwartz, he felt this was a joke but did not become too concerned about it. During a business trip shortly thereafter, a statement of work was formally submitted to the contracting officer which listed among the deliverable items a JOVIAL (Jules' Own Version of the International Algebraic Language) compiler. Nobody would agree to changing the contract, and so the name remained, providing both more fame and more blame to Schwartz than he deserved .{2} The original version of JOVIAL was implemented on both the IBM 709 and the Military Computer used for SACCS (AN/FSQ-31). By no later than May, 196l (and possibly earlier), JOVIAL I became obsolete, was replaced by JOVIAL 2 (running on the 709, 7090, and the SACCS computer), and then eventually by JOVIAL 3. JOVIAL 3 (hereafter referred to as JOVIAL) was implemented at least for the CDC 1604 and 3600, the Philco 2000, the SAGE AN/FSQ-7, and the AN/FSQ-32. JOVIAL 2 was implemented on the IBM 9020.
    As usually happens, even before the compilers were fully operational, work began on improvements to them and the language as well. In May 1960, a decision was made to standardize on JOVIAL as a common programming language for SDC.{3} JOVIAL has been used not only by SDC for Air Force projects but it has been adopted by the Navy for use in its NAVCOSSACT and by the Army in some of its programming efforts. In June, 1967 the Air Force issued its own specifications to establish (a version of) JOVIAL 3 as the standard programming language for Air Force command and control applications (see [AF67]).
    Although JOVIAL has been developed and used primarily by SDC, the history of its development, its modifications, and the implementations on various machines is almost as complicated as that of FORTRAN. Those people interested in further details should see Shaw [SH63b], Steel [ST66], and the references listed in [SH63b]. A list of usage in the Department of Defense and a list of compilers are given in Figure VIII-1.
    JOVIAL tends definitely toward generality and fails somewhere in the middle relative to succinctness and naturalness; this middle ground characteristic occurs because the language is based on ALGOL 58, but it has added so many other features than there is no longer any resemblance. It is consistent and fairly easy to read or write. Since it has great power, it is not particularly easy to learn. The application area includes the whole command and control field, which itself subsumes much of the need for numerical scientific as well as some data-handling calculations, and a particular need for manipulation of logical entities. A significant objective was the necessity of handling system data described in a COMmunication POOL (COMPOOL). While this concept is independent of, and precedes, JOVIAL (e,g., see FAST [MI62]), the ability to use a COMPOOL was a design criterion in the language. The COMPOOL serves as a central source of data description, and it is particularly valuable in the large command and control systems for which JOVIAL was designed and has been used. JOVIAL is a procedure-oriented, problem-oriented, and problem-defining language,Figure VIII-1. JOVIAL usage and compilers. Source: [AA67]The language serves simultaneously as a reference, publication, and hardware language. JOVIAL was designed for the professional programmer and definitely to be used in a batch environment. However, u much later and much simpler version called JTS (see Sandin and Foote [SN65]) was installed under SDC's time-sharing system, and an interpretive extended subset version called TINT was specifically designed and implemented for on-line use. (See Kennedy [KE 65].) JOVIAL has had the misfortune to suffer throughout its history from all the problems that could possibly arise from an attempt to have wide usage, maintain compiler independence, avoid dialects, and control subsetting and extensions. The proliferation of documents and systems on differing machines did not help the situation, although there were continuous attempts in SDC to control this problem. The earliest description seems to he the one by Schwartz, Petersen, and Olson [SC60]. The reader interested in pursuing which versions existed on which machines should see the papers by Shaw [SH63b] and Steel [ST66], but even these are not complete. (See also FigureVIII-l.) There have been several versions of the official specifications with the latest one by Perstein [PE66a], based on earlier ones by Shaw. On the more positive side, in August, 1965 certain internal management decisions were made in SDC with the resulting policy, stated in Perstein [PE66], that any new JOVIAL compiler must implement Basic JOVIAL as defined in that manual. If the new compiler provides capabilities included in 13 (JOVIAL 3), it must implement them in accordance with the official description given in Perstein [PE66a]. A new compiler may implement features that are not included in the specifications of JOVIAL and are not incompatible with the specifications of JOVIAL; of necessity, some features will be machine dependent, e.g., precision of the arithmetic. Since most of the language definitions have been given in a fairly formal way, there has been relatively little problem of incompatibility caused by misunderstanding.
    Until 1967 there was no significant attention paid to JOVIAL from the viewpoint of American standardization (i.e., through USASI), although obviously there has been tremendous attention paid to this within SDC itself. As a result of interest by the Air Force and SDC, there is a possibility that a USASI standard might be developed.
    The original CLIP language work was started by J. Schwartz and E. Book, and the former supervised the development of the first JOVIAL system.{4} Since then, numerous people within SDC have contributed to the further development of JOVIAL; in not all cases were the language designers directly involved with the implementation effort since SDC set up various groups to control the maintenance.
    The basic objective of the language was to create a language for use by professional programmers in solving large complex information processing problems. In the various documents on JOVIAL, several different notations for defining syntax have been used, ranging from reasonable to arbitrary notation that in my opinion did not seem to have any justification whatsoever, the latter appearing, for example, in Shaw [SH63a].
    One complaint which never could be leveled against the JOVIAL activity is a shortage of documentation. Shaw states "My collection of documents of JOVIAL weighs almost 50 pounds and stands almost two feet high .{5} Since that was written in 1962, it seems reasonable that the material has not decreased in quantity. Naturally some of those documents are working papers of interest to limited groups only, but on the other hand at least some of it is of widespread interest. The material ranges from primers (e.g.. Kennedy [KE62]) to detailed syntactic descriptions (e.g., Perstein [PE66a]) to general description and tutorial articles (e.g., Shaw [SH63a] and [SH61}). Other references are listed at the end of the chapter, and still more aregiven in Shaw [SH63b]. Some technical comparisons with other languages are given by Coffman [CO61] and Shaw [SH64]. A JOVIAL Bulletin has been started and issued irregularly as part of SICPLAN notices [AC00].
    JOVIAL appears to have fulfilled its objectives, even though it is perhaps ready to be replaced by PL/I, at least in the view of Steel [ST66]. It seems surprising, however, that although JOVIAL has a potential application area that was wider than any other language until PL/I, and in spite of the fact that it has been implemented on a large number of machines, it does not appear to have been used much outside the military command and control applications (and for writing its own compilers). In that area it has been used more heavily for writing utility and support programs than for the operational programs themselves. Three instances in which JOVIAL has been used in other areas are writing a program to simplify JOVIAL source programs (described by Clark [CE67]), creating a teaching program (see Marsh [MD64]), and automatic essay paraphrasing (see Klein [KK65]). One reason for JOVIAL' s lack of major acceptance seems to be the lack of direct support by computer manufacturers and the natural reluctance by customers to produce a compiler themselves. In some other cases, an NIH (Not Invented Here) factor seems to have played a major role. However, it is not really clear to me why it has not received wider usage outside SDC.
    Extract: Technical details of JOVIAL
    Technical details of JOVIAL

    The character set in JOVIAL consists of the 26 capital letters, the 10 digits, and the following 12 characters:
    + - * / . , = ( ) ? $ blank

    An identifier is a letter followed by at least one letter, a numeral, or an apostrophe, ' (called a prime in JOVIAL) , except that the identifier cannot end with the prime character nor contain two consecutive primes. Hence an identifier cannot consist of a single letter. The five standard graphic arithmetic operators are available.

    Data names and program unit labels are formed as the identifiers defined above, except that they cannot be the same as any of the reserved words in the language. Since statement labels and data names can be distinguished from context, the same name can be used in each of those categories, although this is certainly not recommended because of potential confusion to the user. Data names can have any number of subscripts, separated by commas and delimited by the dollar sign, e.g., ALPHA ($ 3+A*B, B/C $). There is no qualification because there is no data hierarchy except for a limited facility in creating tables. However, it is possible to refer to bits and bytes specifically (which are of course largely or completely machine depen-dent). There are a number of reserved words in JOVIAL, and they cannot be used as names.

    The relational operators are EQ, GR, GQ, LQ, LS, and NQ with the meanings of equal, greater than, greater than or equal, less than or equal, less than, and not equal, respectively. The logical operators are AND, OR, and NOT. Punctuation is used in JOVIAL. but it is not particularly significant except for the commas used to separate items in lists. Much of the delimiting normally done by punctuation (e.g., end of statement) is done through the use of the dollar sign. Blanks are quite significant, and the rules about when they can and cannot appear are complicated; however, the obvious cases where blanks can appear between operators and operands and between key words and names are allowed. Whenever one blank is permitted, any number are allowed. There are no noise words.

    Two types of literals are permitted, namely alphanumeric (denoted as Hollerith) and transmission code; the latter is used to specify the exact form of the machine language representation of the literal. In both cases, the number of characters in the literal precedes the identifying letter. e.g., 4H(NUTS). It is also possible to denote literals by octal constants.

    The format is quite free form, with the programmer being allowed to start any JOVIAL statement in columns 1 to 72; more than one statement per line may be written, and one statement may extend over several lines. The conceptual form seems to fall on rather neutral ground; it is not particularly symbolic or succinct, but on the other hand it is not as Englishlike as COBOL.

    The following is a partial list of the declarations in JOVIAL: ITEM, MODE, ARRAY, TABLE, OVERLAY, DEFINE, PROCEDURE, SWITCH, FILE. Many of these in turn have further declarations associated with them, and all are discussed later.

    The smallest executable unit is a statement containing one of the executable commands; it is terminated by $. Any such statement can be named, and the name is followed by a period. Groups of statements can be combined into a larger form which is composed of a BEGIN and END bracket, with statements (and possibly declarations) between them. These compound statements can be nested to any depth desired. Loops can be controlled by an IF statement or through the use of the FOR command. JOVIAL permits functions, procedures, and closed subroutines. The closed subroutine is a special kind of procedure that has no parameters. There are different rules involving the handling of all these with regard to loops.

    Comments are delimited by two primes (i.e., ") at the beginning and the end; the intervening string can consist of any characters except tile dollar sign and, of course, it cannot contain two primes prior to the end nor a prime immediately preceding the ending pair. A complete program consists of a list of declarations and statements preceded by the key word STARTand optionally preceded by the word CLOSE. If the latter is used, it indicates the program is a closed subroutine. The program ends with TERM $. It is possible to specify the name of the first statement to be executed immediately after the TERM delimiter.

    The only interaction with the environment is from the input/output statements.

    The main delimiter is the dollar sign, which is used to end an executable statement, and of course the BEGIN... END pair for compound statements. Call by name and call by value parameter passage are provided. As indicated above, compound statements themselves can be contained within compound statements. A procedure can invoke other procedures (but no recursion is permitted).

    The executable units and the declarations can be intermingled in the program. It is possible to include machine code statements in a JOVIAL program by preceding the code with the key word DIRECT and following it with the key word JOVIAL. It is also possible to make a definite connection between the variables in the JOVIAL program and a machine register since the programmer is allowed to write ASSIGN A = variablename $ or ASSIGN variablename = A $. The A is considered an undefined machine register called the accumulator.

    JOVIAL introduces the concept of a functional modifier which provides built-in operations on certain types of expressions or conceptually provides answers to questions about various program items. From a structural viewpoint, functional modifiers seem to fall between direct executable statements and declarations, although they actually appear in statements.

    The types of data variables and constant permitted in JOVIAL are arithmetic, Boolean, status, literal, and dual. Status variables are essentially mnemonic names which can be associated with integer values of a data variable and can be tested against these values. (This is the same concept as the conditional variable in COBOL.) The dual constants represent an ordered pair which is not a rational number but is useful for calculations involving two-dimensional coordinate systems; it is only implemented on machines with dual arithmetic and was motivated by the early existence of such hardware. Arithmetic variables can be fixed, integer, or floating point. There are no complex, formal, string, or list variables. Arithmetic expressions are created in the normal way. Absolute value is designated by either (/ /)  or ABS ( )

    There are both tables and arrays in JOVIAL. An array is an n-dimensional collection of values or variables of the same type, all identified by a single name (with the necessary subscripts). A table on the other hand is a onedimensional array, each element of which contains a fixed but arbitrary number of data items of (possibly) different types, For implementation reasons, tables are handled more efficiently. JOVIAL permits access to bits and bytes through functional modifiers BIT and BYTE by writing, e.g., BIT ($ 0, 6 $) (COLUMN)or BYTE ($ 3 $) (STATE). In the first case, the information designated is an unsigned integral variable, and it can be assigned to another variable name (which can itself be designated through the BIT modifier). The BYTE modifier designates a literal variable. The first bit or byte of the data item and the number of bits or bytes are specified by the two numbers associated with the modifier, and the number (of bits or bytes) can be omitted if it is 1.

    All the data variables, constants, and aggregates of constants are accessible by the commands in JOVIAL.

    There are three types of arithmetic in JOVIAL: Floating point, fixed point, and dual fixed point. In the dual mode, operations are done in parallel with the left component of one operand combined with the left component of the other to yield the left component of the result. (This is a special case of more general array operations.) Operands of different modes can be combined, and automatic conversions from fixed to floating, floating to fixed, and fixed (or floating) to dual are implied. In the last case, the singlevalued operand is duplicated before doing the arithmetic. The precision of the arithmetic result is computer dependent because of the word size. Standard precedence and sequencing rules apply except that the unary minus takes precedence over exponentiation, e.g., -3**2=9.

    Boolean expressions are constructed in the standard way from the three operators AND, OR, and NOT. Parentheses are used to indicate grouping when necessary. The status variables can be included within a Boolean formula.

    Names defined within a procedure are defined only for that procedure, and they can be used outside it with a different meaning. Names defined within a program apply only to that program when it is used in conjunction with others. Names in a COMPOOL (described briefly on page 536) are defined for an entire system of programs, excluding programs or procedures that define identically spelled names. Names of data elements not defined in a COMPOOL should be defined before they are used. If they are not, a preset (compiler dependent) mode is assigned; this can be changed by the MODE directive.

    JOVIAL has a basic assignment statement; in addition, it permits theinterchange of values of a pair of variables; this is designated by two equals signs. In both cases, the numeric quantities on the right are converted to the appropriate form on the left. Thus, writing the sequence

    A = 5 $ B =7 + A $ A = = B $

    causes A to have the value 12 and B to have the value 5.

    There are no specific alphanumeric data-handling commands, although the easy access to bits and bytes make their programming fairly simple.

    The unconditional control transfer is the (single word) GOTO. It may have statement label information with it, to provide both a computed and an assigned GOTO. This command can be used to invoke a subroutine with no parameters permitted; after execution of the subroutine, control is returned to the statement immediately following the Gala unless there has been a transfer of control out of the subroutine. Procedures with formal parameters are invoked by specifying the procedure name and a list of the parameters enclosed in parentheses and separated by commas; an equals sign is written between the input and the output parameter lists to distinguish between them.

    A function can be invoked from within an arithmetic or Boolean expression.

    Conditional statements take one of two forms. The first is itself called a conditional statement by JOVIAL writers and is of the form IF Boolean-expression $ statement where the statement cannot contain an IF except within a BEGIN... END bracket. Thus, IF AR EQ BJ $ CR = DK + EM $ and IF ALPHA - BETA LS GAMMA + DELTA $ BEGIN IF HE EQ SHE $ GOTO BLAZES $ END are correct, but IF ALPHA - BETA LS GAMMA + DELTA $ IF HE EQ SHE $ GOTO BLAZES $ is not correct because the second IF is not within a BEGIN ... END bracket.

    Another form of conditional statement provides alternatives, using the following format:

    IFEITH Boolean-expression $ statement [label . ] 0RIF Boolean-expression $ statement [label . ] 0RIF Boolean-expression $ statement ... END

    where [ ] indicate optional elements. Any number of alternatives can be listed, and the Boolean expressions are tested in sequence from the top; the statement associated with the first true Boolean-expression is executed and control is then passed to the statement following the END. For example,Figure Omitted

    In this example, if AB > BB, then AB = CD is executed and control passes to NEXTST. If AB {} BB, then control passes to NAME and the AB + CD < CD test is made. Depending upon its truth value, either the three statements following the BEGIN are executed or else control passes to the next ORIF; in that case, since the 1 is defined as the Boolean constant true, control is passed to WARM.

    The loop-control statement is the FOR statement, which has the following general format;

    FOR paramlist {} $ [name .] FOR paramlist2 $... $ [name .] FOR paramlistn $ BEGIN statements END

    the range of the FOR is the set of statements contained within the BEGIN... END pair. The paramlist is of the form

    parameter = initial-value, increment, final-value $ or parameter = ALL (name) $

    where the parameter is a single letter defined only within the range of the FOR, any of the three elements can be expressions, and the final value can be omitted (in which case the loop must terminate from within the range). The parameters following each separate FOR statement are varied in parallel, i.e., the initial value of each is set, then each is incremented, etc.; nesting is accomplished by including a FOR statement within the BEGIN ... END pair. Only one paramlist can contain a final-value for its parameter. In the use of the ALL case above, the name refers to a table or an item in a table, and the looping is executed for each element in the table. The value of a parameter can be used in an expression to determine the value of a parameter that appears in a succeeding FOR paramlist.

    A rather unusual TEST [parameter] statement exists. It permits control to transfer to the compiled code which causes incrementing and testing of a parameter in a loop.There are no error condition statements nor any symbolic data-handling statements.

    With regard to input/output, it is worth noting that neither JOVIAL 1 nor JOVIAL 2 on the 709/7090 contained any input/output commands because the executive program that they were using did all the input/output. The input/output commands that were finally put into JOVIAL look much like COBOL, although they are not necessarily based on it. The first time a file is activated, the user must give an OPEN INPUT filename [recordinformation] $. Subsequently the user writes INPUT filename recordinformation $. The recordinformation can either be a variable name, an array name, a table name, sequences or table entries, or an individual table entry. The file is shut by means of a SHUT INPUT filename [recordinformation] $ statement. The actual READ operation transfers the information From the physical file into internal storage. Similarly, for output, the user would write OPEN OUTPUT filename [recordinformation] $ the first time, OUTPUT filename [recordinformation] $ the rest of the time, and then SHUT OUTPUT filename [recordinformation] to close the file and deactivate it. For each logical record read or written, the file position, accessed by the functional modifier POS (filename) is incremented by one.
    There is only one built-in function in JOVIAL, namely REM, and there is a built-in procedure REMQUO. They produce, respectively, the remainder and the remainder and quotient of division of two integers. Procedures and functions in the library are made part of the object program by just writing the names in the source program. The COMPOOL contains descriptions or definitions of both data declarations and programs. Any reference to data, procedures, or functions that are listed in the COMPOOL will be used as if they were a part of the program, unless the program itself defines such a name explicitly prior to its usage.

    There are no specific executable debugging or storage allocation statements. The only type of interface with an operating system is through the COMPOOL. The closest to machine feature statements are the availability of the bit and byte modifiers and the provision for a mythical accumulator.

    The basic units of data are called items, and the most basic data declaration is the ITEM, which must be written for each variable. A MODE declaration describes the item and provides an implicit declaration For all following and otherwise undefined simple items until another MODE declaration occurs.

    The ARRAY declaration provides the dimensions along with the rest of the ITEM declarations. Associated with each item are a number of characteristics. Some are either self-explanatory or have already been described, namely floating, fixed, integer, dual, signed, unsigned, Hollerith, transmission, status, and Boolean. Many of these are written using only the initial letter, e.g., P specifies floating point.

    A rounded attribute declares that any value assigned to the item shouldbe rounded rather than truncated. It is also possible to show for each variable an estimated minimum and maximum absolute value of the item. For each status item, the list of status constants is given; these are encoded in order by the integers 0, l, 2, etc. The number of bits can be specified but if it is omitted, then the compiler determines the maximum number of bits required.

    It is often desirable to assign specific initial values; this can be done by inserting a preset declaration immediately after the name and description. As an illustration, the declaration

    ITEM ALPHA I 15 U 5 P 97.18 $

    describes a variable named ALPHA as an Unsigned 15 bit Integer with 5 fractional bits which is Preset to the value 97.18.

    There are TABLE and ARRAY declarations. For the table, it is possible to specify variable or rigid (= fixed) lengths; serial or parallel entry structure; and either no item packing, medium item packing, or dense item packing. A variable table declaration indicates that the number of entries can vary during program execution, whereas for a rigid table length this cannot be done. The difference between serial and parallel entry tables is the way in which their data is stored. In the serial table, words needed for an entry are allocated consecutive memory positions; whereas in the parallel structure the nth word of each entry resides in a contiguous block of memory. The density of packing indicates how the items are to be stored within a particular entry. No packing means that each item is allocated a full word; medium packing means that storage is allocated in subword units, where these subunits can be of different sizes within the word and are of course completely machine dependent; finally, dense packing means that the storage is allocated primarily in consecutive bit positions. (Note that the language is heavily oriented toward a binary machine; it does not seem to have been implemented on a decimal machine.) If packing is not specified, then each compiler assumes some normal packing mode. (More recent specifications provide rules for this.) It is possible to define a table structure completely through the use of the structured item declaration and the STRING item declaration (which declares more than one occurrence of the item per entry of a table). This plus some other facilities allow the user to specifically indicate what item appears in what part of a word. Obviously this plays havoc with machine independence.

    The NENT (number-of-entries) is a parameter indicating the number of entries in a table. Thus one can write

    NENT (PAYROLL) = NENT (PAYROLL) + 1 $

    if one wants to add somebody to tile payroll. For fixed length tables this isan integer constant, while for variable length tables it is a counter that the program itself must maintain. Another parameter for table processing is NWDSEN (number-of-words-per-entry) which is an integer constant established at compile time. The ALL modifier was already seen in the FOR clause to permit more effective processing of tables. The ENTRY modifier allows a table entry to be treated as a single value. The MANTissa and CHARacteristic modifiers permit the user to extract the indicated information from a floating point variable and assign it to another variable. The ODD modifier can be used to determine if the value of the least significant bit of a quantity is 0 or 1; it can be assigned to a Boolean variable which will then be true if it is odd and false if it is even.

    The file declaration is of the following form:

    FILE filename filestructure statuslist devicename $

    where the filestructure specifies Hollerith or binary, the estimated maximum number of records, fixed or variable record size, and estimated maximum number of bits or bytes in a record. The list of possible file statuses, e.g., busy, ready, and error, are associated with integer values as status constants. The devicename is defined by the implementer, but it is assigned by the programmer.

    The overlay declaration is the word OVERLAY followed by a sequence of overlay lists; storage is assigned sequentially to the data elements in each list and each separate list can occupy the same space as another.

    Finally, JOVIAL contains a DEFINE declaration which permits a name to be substituted for a string. It is written DEFINE name "definition" $. It can be used, for example, to abbreviate lengthy expressions, introduce noise words, or make key words more readable, e.g.,

    DEFINE AREA "3.1416 * RADIUS ** 2" $ DEFINE NUTS ? ? $ DEFINE GREATER "GR" $

    Procedure declarations usually have the following form:

    PROC name (inputparamlist = outputparamlist) $ [declaration list] BEGIN statements END

    The items in the paramlists are separated by commas. A function declaration also uses PROC, and the name is used as the output parameter.

    The STOP statement terminates execution; however, a statement label can he written after the STOP statement, and if execution is resumed, then the indicated statement will be the next one executed.

    Switch declarations also exist. The word SWITCH is followed by anidentifier and then a sequence of identifiers in parentheses. The choice is determined as a computed GOTO (see Section III.5.3.1).

    There is no self-modification of programs. There is also no self-extension of the language, except in the trivial sense permitted by the DEFINE which allows the user to substitute a name for a string. There are no specific compiler directives.
    Extract: Impact of JOVIAL
    JOVIAL is the best documented and practical example of a language which can be used to write its own compiler. Almost all the recent JOVIAL compilers have been written that way, and even JOVIAL 1 was bootstrapped using itself. Most of the JOVIAL compilers are structured with a generator which accepts the source code, translates into an intermediate language and then a translator which converts the intermediate language into executable machine code. (In my opinion, these people are using the terms generator and translator backwards. However, they picked up this terminology from the early work on the UNCOL concept (see Section X.2).) Not only does this procedure make it easier to construct new compilers, but it also helps significantly with the documentation and somewhat with compatibility problems because both the generator and the translator themselves are written in JOVIAL.
    It is clear that JOVIAL has been designed to provide efficiency at object time. The facilities for structuring the data internally all lead to efficient storage allocation and execution, with a minimum amount of incompatibility. Although the language is fairly general, there are annoying restrictions in it. Since the programmer is able to specify and control the storage allocation considerably through the declarations, the compiler needs to obey only the specifications given for each program. There are no particular debugging aids or error checking in the language, although most of the compilers provide them.
    JOVIAL appears to have made several contributions to the technology. It was the first language (and until PL/I, the only one) to provide good facilities for simultaneously doing scientific numerical computation and nontrivial data handling, while at the same time it could also be used in general information handling areas. A second contribution, although not really introduced by JOVIAL, is the use of the COMPOOL (see Section 4.2 in Perstein [PE66a]) in connection with a compiler. A third contribution to the technology is its practical usage as its own compiler. Finally, it has made a very significant contribution in terms of allowing the programmer great flexibility for controlling storage allocation when he needs to but not requiring him to do so otherwise
          in [ACM] CACM 11(02) (February 1968) view details
  • Schwartz, J. I. "ADVANCED DEVELOPMENT PROTOTYPE SYSTEM Final Report (Part 1) to the Director, Advanced Research Projects Agency for the period 30 July 1968 to 30 January 1969" SYSTEM DEVELOPMENT CORPORATION 2500 COLORADO AVE. SANTA MONICA CALIFORNIA 90406 view details
          in [ACM] CACM 11(02) (February 1968) view details
  • Stock, Karl F. "A listing of some programming languages and their users" in RZ-Informationen. Graz: Rechenzentrum Graz 1971 131 view details Abstract: 321 Programmiersprachen mit Angabe der Computer-Hersteller, auf deren Anlagen die entsprechenden Sprachen verwendet werden kennen. Register der 74 Computer-Firmen; Reihenfolge der Programmiersprachen nach der Anzahl der Herstellerfirmen, auf deren Anlagen die Sprache implementiert ist; Reihenfolge der Herstellerfirmen nach der Anzahl der verwendeten Programmiersprachen.

    [321 programming languages with indication of the computer manufacturers, on whose machinery the appropriate languages are used to know.  Register of the 74 computer companies;  Sequence of the programming languages after the number of manufacturing firms, on whose plants the language is implemented;  Sequence of the manufacturing firms after the number of used programming languages.]
          in [ACM] CACM 11(02) (February 1968) view details
  • Rosen, S. "Programming Systems and Languages 1965-1975" view details Abstract: In spite of impressive gains by PL/I, Fortran and Cobol remain the languages in which most of the world's production programs are written and will remain so into the foreseeable future. There is a great deal of theoretical interest in Algol 68 and in extensible languages, but so far at least they have had little practical impact. Problem-oriented languages may very well become the most important language development area in the next five to ten years. In the operating system area all major computer manufacturers set out to produce very ambitious multiprogramming systems, and they all ran into similar problems. A number of university projects, though not directly comparable to those of the manufacturers, have contributed greatly to a better understanding of operating system principles. Important trends include the increased interest in the development of system measurement and evaluation techniques, and increased use of microprogramming for some programming system functions. DOI
          in [ACM] CACM 15(07) (July 1972) view details
  • Sammet, Jean E., "Roster of Programming Languages 1972" 141 view details
          in Computers & Automation 21(6B), 30 Aug 1972 view details
  • Sammet, Jean E. "Roster of Programming Languages for 1973" p147 view details
          in ACM Computing Reviews 15(04) April 1974 view details
  • Stock, Marylene and Stock, Karl F. "Bibliography of Programming Languages: Books, User Manuals and Articles from PLANKALKUL to PL/I" Verlag Dokumentation, Pullach/Munchen 1973 311 view details Abstract: PREFACE  AND  INTRODUCTION
    The exact number of all the programming languages still in use, and those which are no longer used, is unknown. Zemanek calls the abundance of programming languages and their many dialects a "language Babel". When a new programming language is developed, only its name is known at first and it takes a while before publications about it appear. For some languages, the only relevant literature stays inside the individual companies; some are reported on in papers and magazines; and only a few, such as ALGOL, BASIC, COBOL, FORTRAN, and PL/1, become known to a wider public through various text- and handbooks. The situation surrounding the application of these languages in many computer centers is a similar one.

    There are differing opinions on the concept "programming languages". What is called a programming language by some may be termed a program, a processor, or a generator by others. Since there are no sharp borderlines in the field of programming languages, works were considered here which deal with machine languages, assemblers, autocoders, syntax and compilers, processors and generators, as well as with general higher programming languages.

    The bibliography contains some 2,700 titles of books, magazines and essays for around 300 programming languages. However, as shown by the "Overview of Existing Programming Languages", there are more than 300 such languages. The "Overview" lists a total of 676 programming languages, but this is certainly incomplete. One author ' has already announced the "next 700 programming languages"; it is to be hoped the many users may be spared such a great variety for reasons of compatibility. The graphic representations (illustrations 1 & 2) show the development and proportion of the most widely-used programming languages, as measured by the number of publications listed here and by the number of computer manufacturers and software firms who have implemented the language in question. The illustrations show FORTRAN to be in the lead at the present time. PL/1 is advancing rapidly, although PL/1 compilers are not yet seen very often outside of IBM.

    Some experts believe PL/1 will replace even the widely-used languages such as FORTRAN, COBOL, and ALGOL.4) If this does occur, it will surely take some time - as shown by the chronological diagram (illustration 2) .

    It would be desirable from the user's point of view to reduce this language confusion down to the most advantageous languages. Those languages still maintained should incorporate the special facets and advantages of the otherwise superfluous languages. Obviously such demands are not in the interests of computer production firms, especially when one considers that a FORTRAN program can be executed on nearly all third-generation computers.

    The titles in this bibliography are organized alphabetically according to programming language, and within a language chronologically and again alphabetically within a given year. Preceding the first programming language in the alphabet, literature is listed on several languages, as are general papers on programming languages and on the theory of formal languages (AAA).
    As far as possible, the most of titles are based on autopsy. However, the bibliographical description of sone titles will not satisfy bibliography-documentation demands, since they are based on inaccurate information in various sources. Translation titles whose original titles could not be found through bibliographical research were not included. ' In view of the fact that nany libraries do not have the quoted papers, all magazine essays should have been listed with the volume, the year, issue number and the complete number of pages (e.g. pp. 721-783), so that interlibrary loans could take place with fast reader service. Unfortunately, these data were not always found.

    It is hoped that this bibliography will help the electronic data processing expert, and those who wish to select the appropriate programming language from the many available, to find a way through the language Babel.

    We wish to offer special thanks to Mr. Klaus G. Saur and the staff of Verlag Dokumentation for their publishing work.

    Graz / Austria, May, 1973
          in ACM Computing Reviews 15(04) April 1974 view details
  • Cheatham T. E. "A brief description of JOVIAL" view details Abstract: programming languages  
    JOVIAL (Jules' Own Version of the International Algebraic Language) was one of the first programming languages developed primarily to aid in programming large complex real time systems. Today it remains a major language for these applications and versions of JOVIAL have been implemented on dozens of different computers. The language and its compilers have been developed primarily by the Systems Development Corporation. JOVIAL was based on Algol-58 but includes numerous features not in Algol (58 or 60) which make it particularly useful for programming large scale systems. The most important of these is the COMPOOL (communications POOL), a central repository of data descriptions which permits programmers to reference data items without concerns as to how they are represented on some particular computer.

          in SIGPLAN Notices 14(04) April 1979 including The first ACM SIGPLAN conference on History of programming languages (HOPL) Los Angeles, CA, June 1-3, 1978 view details
  • Sammet, Jean E "Roster of programming languages for 1976-77" pp56-85 view details
          in SIGPLAN Notices 13(11) Nov 1978 view details
  • Schwartz, Jules I. "The development of JOVIAL" view details Abstract: The time was late 1958. Computers that those who were involved with the first JOVIAL project had been using included the JOHNNIAC (built at Rand Corporation), the IBM AN/FSQ-7 (for SAGE), 701, and 704. A few had worked with board wired calculators. Some had never programmed. For those using IBM, the 709 was the current machine. There were various other manufacturers at the time, some of whom do not exist today as computer manufacturers. The vacuum tube was still in vogue, Very large memories, either high speed direct access or peripheral storage, didn't exist, except for magnetic tape and drums on some computers. Extract: Beginnings
    JOVIAL really got its beginning because of the launching by the Air Force of another large system. This one followed SAGE and it was called the SACCS System. SACCS was to be developed from scratch. This meant new computers, a new system, new programming techniques, and a new operating (executive) system. All of these had to be developed before the operational program could be developed. The main computer was the IBM AN/FSQ-31. Other Communications Computers
    (built by ITT) were also utilized. Extract: Origins
    The time was late 1958. Computers that those who were involved with the first JOVIAL project had been using included the JOHNNIAC (built at Rand Corporation), the IBM AN/FSQ-7 (for SAGE), 701, and 704. A few had worked with board wired calculators. Some had never programmed. For those using IBM, the 709 was the current machine. There were various other manufacturers at the time, some of whom do not exist today as computer manufacturers.

    The vacuum tube was still in vogue, Very large memories, either high speed direct access or peripheral storage, didn't exist, except for magnetic tape and drums on some computers.

    The first large scale system which was built and maintained by thousands of people was in the process of being installed after a considerable amount of effort, expense, and technological innovation. Called SAGE, it was a large real-time system (very large by 1958 standards).

    It had, among other things, an interesting and very valuable (even by today's standards) utility system for assisting in development. This included the Communication Pool. The Comm Pool's purpose was to permit the sharing of System Data among many programs by providing a centralized data description. Programming for SAGE had been done in machine language, as was almost all programming up to that time.

    FORTRAN existed and had been in use for a few years, but use of higher level languages wasn't nearly as common as the use of such languages today. Certainly the majority of people involved in compiler efforts at that time, and in particular the initial JOVIAL language development and compiler effort, had almost no experience
    with such activities. I had had experience with the language and compiler called PACT (Project for Automatic Coding Techniques) which was developed and described in 1954-1955 (Melahn 1956). But actually this experience, largely because of the nature of that language
    and the computer the first version ran on (the IBM 701), was not particularly valuable for the development of languages in the ALGOL class.

    One of the significant things that got the JOVIAL language
    and compiler work started was an article on Expression Analysis that appeared in the 1958 ACM Communications (Wolpe 1958). The fact that this was actually quite a revelation to us at that time seems interesting now. Since that day, of course, there have been many developments in the parsing of mathematical and logical expressions. However, that article was the first exposure many of us had to the subject. Some of us who had just finished work on some other projects
    (including SAGE) began experimentation with the processing of complex expressions to produce an intermediate language utilizing the techniques described. There was no compiler language at the time in our plans, but the idea of being able to understand and parse complex expressions in itself was of sufficient interest to motivate
    our efforts.

    Another article which was to have great influence on our future development was also published in the ACM Communications in 1958. This was the description of what was then called the International Algebraic Language (IAL, later called ALGOL), which had been defined by what became (and for the most part had been) an esteemed group of computer people (Perlis and Samuelson 1958). Extract: The Technical Base for JOVIAL
    The Technical Base for JOVIAL
    The two major influences on the language of JOVIAL were, first, the International Algebraic Language, which served as the language architectural base, and SAGE, which contributed to the knowledge of many of the problems and ideas needed to solve the large programming system problem. IAL was chosen as the base language for several reasons. One was that at the time it appeared as ff it would become the commonly accepted standard for languages. Secondly, it seemed like a better technical basis for a new language than FORTRAN, which was the only other possibility. SAGE influenced such matters as data handling, Communication Pool, and the need for a variety of types of variables (items or elements). These things were deemed essential to the programming of SACCS and served as the basis for the first definition of JOVIAL.
          in SIGPLAN Notices 14(04) April 1979 including The first ACM SIGPLAN conference on History of programming languages (HOPL) Los Angeles, CA, June 1-3, 1978 view details
  • Gnugnoli, G. review of Shaw et al SPE 1981 in ACM Computing Reviews June 1981 view details Abstract: The authors present a methodology for the comparison of languages. Their objective is to define an underlying "core" portion of the language which is brief, which represents the intention of the designers, which fairly represents the essence of the language, and which encompasses those features of the language which allow implementation of modern software engineering techniques. They illustrate this concept by defining and comparing cores of four languages -- FORTRAN, COBOL, JOVIAL, and Ironman (ADA).

          in SIGPLAN Notices 14(04) April 1979 including The first ACM SIGPLAN conference on History of programming languages (HOPL) Los Angeles, CA, June 1-3, 1978 view details
  • Shaw, Mary; Almes, Guy T.; Newcomer, Joseph M.; Reid, Brian K.; and Wulf, W. A. "A comparison of programming languages for software engineering" Software Practice and Experience 11(01) January 1981 pp1-52 view details
          in SIGPLAN Notices 14(04) April 1979 including The first ACM SIGPLAN conference on History of programming languages (HOPL) Los Angeles, CA, June 1-3, 1978 view details
  • Allen, F. and Schwartz, J. review of Sammet and Lee HOPL conference end banquet excerpts view details Abstract: The ACM-SIGPLAN History of Programming Languages Conference held in Los Angeles on June 1-3, 1978, was videotaped and excerpts of the presentations are available on two tapes; these and two tapes from the banquet provide brief but penetrating glimpses of the people most involved in the development of the 13 languages covered. At the conference and in the proceedings these leading formulators of the history of programming languages describe how their language was developed -- the historical setting of the work and how and why decisions were made. The videotape excerpts provide a summary of these descriptions.

    After introductory remarks, Jean Sammet, the Conference and Program Committee Chairman, introduces the keynote speaker and "the third programmer of the first large scale digital computer, Mark I," Capt. Grace Hopper of the US Navy. Capt. Hopper describes the very early history -- combining personal recollections and technical observations. It is an excellent historical talk, precisely establishing the milieu existing in the 1940s and early 50s, when the concept of using a computer to create programs was just emerging.

    The FORTRAN presentation by John Backus emphasizes the importance of object efficiency for FORTRAN acceptance. He states that language design was never considered a problem; the real problem was to consistently produce object programs as efficient as hand-coded ones. The presentation captures the clear and unwavering focus of Backus's original team on that goal: a focus and dedication which characterized the direction of one of the most significant software projects in the history of computers.

    The controversies in the committee designing ALGOL 60 are re-enacted in miniature on these tapes. Alan Perlis describes the American contributions, concluding that ALGOL has Influenced all languages since that time. "It's the mother's milk of us all." Peter Naur describes the European contributions and the origins of recursion in the language. A lively floor discussion involving John McCarthy, John Backus, and Fritz Bauer ensues. The Algol 60 committee got involved in "academic log rolling" according to McCarthy who also points out that the committee decision not to consider implementation led to a language which was not implementable as a whole. It was assumed that "everyone was a gentleman and none would propose something he didn't know how to implement. However there was no guarantee the combination was implementable."

    The excerpt on the LISP lecture by John McCarthy emphasizes the features of the language and is an excellent description of its intellectual sources. Jean Sammet in presenting COBOL also clearly defines the influences on the language and how and why the choices were made in a series of committee meetings. These choices were very much colored by the decision to take "a short range composite approach good for at least a year or two."

    The tapes show how differently some of these important languages developed. According to Douglas Ross, APT evolved out of application requirements; by contrast, the major features of JOVIAL were developed in a few minutes, relates Jules Schwartz, its sole designer. Geoffrey Gordon tells how GPSS also grew from feedback from application users. SIMULA, developed by Kristen Nygaard and Ole-Johan Dahl, didn't even start as a programming language. Charles Baker discusses the development of JOSS, and Thomas Kurtz, BASIC -- intended to make learning to program analogous to learning to drive a car: by doing it.

    PL/I was the largest language represented at the conference. According to presenter, George Radin, much of the complexity and size is due to the necessity of defining the result of all operations on mixed types and to implicit typing. The excerpts of the presentations on SNOBOL by Ralph Griswold and APL by Kenneth Iverson establish the specific motivations for those languages: in both cases conserving human resources was considered very important.

    The conference banquet tapes contain anecdotes by the conference speakers and by master of ceremonies Bernard Galler. These entertaining historical asides and footnotes sometimes give more insight into the how and why things happened than the more scholarly analyses. For example, George Radin's story about the PL/I committee's ordering pizza -- the pizza had everything anyone wanted -- says a great deal about how the committee functioned when designing the language.

    These tapes constitute an important historical record. Unfortunately, the quality of the tapes is less than desired. They were not professionally produced and the picture quality is often quite poor. Still-photos by Robert McClure and Richard Wexelblat are used where the videotape is inadequate. However, the excerpts have been well selected by J.A.N. Lee, Jean Sammet, and Henry Tropp.

    In his summary Fred Brooks says that "the best thing about this conference is the character set." He also points out that the presentations on the languages designed by a committee emphasized the process, whereas the presentations on single-author languages emphasized technical issues. These tapes capture the factors that have made the history: the personalities, the process, and the technology. They are interesting now and will be invaluable to future historians of the pioneering period of language development.
          in ACM Computing Reviews March 1982 view details
  • Dorn, P. H. review of Schwartz, 1982 view details Abstract: The development of JOVIAL.
    During the HOPL conference in the late spring of 1978, many a serious computer scientist and researcher expounded at considerable length as to why certain features were included or excluded from various languages. The discussions seemed to always say that the features were proposed, various position papers were circulated, formal sessions were held at which the matter was debated and the implications analyzed, and finally, a consensus decision was reached.

    By way of contrast, Jules Schwartz, the "J" in JOVIAL, casually admitted that most of the language's features were developed almost instantly. He cited Data Definition as requiring 30 minutes, the Item Switch as requiring only minutes, but did admit that the STRING Item took more than one day because the compiler implementation people saw troubles ahead.

    Schwartz's paper and informal remarks make it very clear that JOVIAL was neither an academic exercise nor an attempt to gain immortality by developing "the" language of the decade. What it was in essence was an effort to build a language for programming large systems. The language would be flexible, reasonably machine-independent and well suited for systems programming. How well the group succeeded is evidenced by the wide number of JOVIAL implementations, the many machines on which it exists, and the hundreds of thousands of hours of JOVIAL programs that have run since the early '60s.

    In an almost casual afterthought, Schwartz mentions that after the initial version was completed, all subsequent versions were able to compile themselves. This is no mean achievement. Hardly a compiler exists today that can compile itself, although there are a few. Somehow, the thought of COBOL written in COBOL is slightly mind boggling. BASIC in BASIC seems unlikely, at least in pure versions. Doing a FORTRAN compiler in FORTRAN is probably feasible today -- after all, the language is nearly 25 years old -- but for a long time, it just wouldn't do the job.

    The basic driving forces behind JOVIAL were two. First, the IAL report had appeared and a solid set of basic, high-level language concepts were on paper. Second, there was the influence of the SAGE system and its very special, almost unique, attributes. For those unfamiliar with SAGE, a 1982 retrospective study of the massive air defense system would be valuable. Just a few of its unusual features were: 1) the Communications Pool, an early data definition mechanism, which permitted easy sharing of the data; 2) centralized input/output provided by the control programs in the system; 3) asynchronous handling of interrupts by control programs, leaving the "applications" programs free from bother; 4) a special program for simulating external inputs that greatly eased testing of any single new module in a large system; 5) dual machine operation with automatic switchover and frequent transfers of data between the active and standby systems; 6) online terminals, 96 of them; and 7) data communications to other systems. This in 1958!

    Why didn't early JOVIAL versions have input/output? It wasn't necessary for programming SAGE or its successor, SACCS, Air Force contract 465-L in its formal nomenclature. There should be no misunderstanding here: Schwartz and his team were trying to solve specific, not general problems.

    The paper and Schwartz's presentation at HOPL describe a way of working unknown in these days of formal project mechanisms with CPM charts, inflexible reporting structures, and strict deadlines. JOVIAL was designed and implemented in parallel, put together by interaction among the team members, had no detailed plans or schedules, was changed by things uncovered when writing the compiler or from early user input, and had no committees at all. As Schwartz said: "The fact that there were no committees involved in the original version of JOVIAL, was, I believe, good for the development." Why? "One couldn't define things in minutes with committees."

    The JOVIAL project wasn't large, about 9 people at first, 15 or so later on. This made for a certain amount of informality as well as speed in getting the results distributed. The first version -- an interpreter, incidentally -- was available in 12 months. The 709 version, one of the two earliest, was heavily used after about 25 man-years of effort. Compare this to the PL/I or ADA implementations.

    The materials presented in this paper are not very formal; no attempt was made to produce a full history of the JOVIAL project or a detailed language description. In any event, even Schwartz admits he doesn't have a copy of what might be called the seminal paper, 7-8 pages of onionskin produced in December 1958. Fortunately, there were, and are, hundreds of available copies of the formal JOVIAL language description.

    The SAGE influence permeates JOVIAL' s history. The importance of the IAL paper was only in getting started; thereafter it was hardly a factor. But, accepting the COMPOOL (that was the SAGE spelling) notion meant that each individual program written in JOVIAL rarely had to worry about the size, location, or possible contents of important variables. All the programmer really had to know was the name and what might be in the Item. How come it took the commercial world 20 years to barely catch up with the same notion? Now it is called data definition and tied closely to the functioning of a DBMS.

    Reviewing a paper on JOVIAL is "difficult" for an old-time SAGE type. It's a nostalgia trip to simpler days when things were, dare we say it, fun. There was a job to be done, and people did it without worrying much about the formalities, the politics, or the long-range implications. JOVIAL itself was widely used and lasted a long time. There are still hundreds of JOVIAL programs functioning. From a number of JOVIAL concepts have emerged bits and pieces of CORAL, SYMPL, SPL, CMS II, and possibly (even though it has never been acknowledged) PL/I.

    Was it a "good" language? That's hard to answer. Schwartz notes: "The main thing proven by some of this is that we haven't mastered the art of comparative studies." Perhaps the important thing about JOVIAL was that it did what it was supposed to do, provide a flexible tool for building large- scale systems.

    This paper is very readable and most enjoyable. It tells what people interested in programming language history needed to know, namely that JOVIAL was tossed together in a hurry by a small group of bright people working within a special, well- defined framework. More than this cannot really be expected from a paper of this nature. That big book on SAGE, what it was and what it meant to the infant computing industry, is still waiting to be written.


          in ACM Computing Reviews March 1982 view details
  • Steel, T. B. review of Wexelblat 1982 view details Abstract: This compendium is a magnificent book, belongs on the shelf of every information processing professional, and should be required reading for anyone who is to be granted a degree in computer science. While the book purports to be the record of the ACM SIGPLAN Conference on the History of Programming Languages held in Los Angeles in 1978, it is rather more than just that. It is an impressionist painting of a longvanished world whose inhabitants created a structure that has a profound influence, not only today but well into the foreseeable future, on the way all our institutions, commercial, governmental, or academic, conduct their affairs. The languages used to prepare computer programs dictate in many respects the thought patterns of the programmers, the questions they ask their users, the difficulty of implementing particular algorithms, and thus to a considerable extent what actually gets done. Beyond that, while it is premature to predict detailed effects, the consequences to the next generation of being taught these languages in school are certain to be enormous. The volume under review presents an account of how this structure came to be the way it is as seen through the eyes of some of the individuals responsible.

    It is a difficult book to review adequately. One must ask if it conveys the same message to that vast majority of information processing specialists who were not in the business at the time of the events recounted as it does to those of us who played an active role in some of the developments as they happened. Judicious inquiry of younger readers of the book suggests that rather more of the informal flavor comes through than one might suspect at first. In that sense the book "tells it like it was," although some of the text makes it quite clear that programming language designers have the same kind of selective and prismatic memories that other people have.

    The plan of the book is straightforward. Thirteen specific languages were selected by the conference organizers, and the book contains, for each language: a formal paper; a transcript of the presentation; a transcript of remarks by a designated discussant; a transcript of a subsequent question and answer session; the full text of all questions submitted; a biography of the authors. In addition there is the full text of the Keynote Address presented by Captain Grace Murray Hopper, itself required reading, and a series of appendices, including summaries of each language.

    As stated in the introductory material on the organization of the conference, the criteria for selection of the languages to be included were: "that the languages 1) were created and in use by 1967; 2) remain in use in 1977; and 3) have had considerable influence on the field of computing." The 1967 cutoff was to insure at least ten years perspective. The result of applying these criteria was:

    ALGOL 60
    APL
    APT
    BASIC
    COBOL
    FORTRAN
    GPSS
    JOSS
    JOVIAL
    LISP
    PL/I
    SIMULA
    SNOBOL

    This general review cannot pursue the specific language chapters; that is a task for individual reviews elsewhere in CR. Some overall comments are in order, however. The formal papers are not simply personal recollections of the authors. An organized procedure was established to guide each author in preparing an account according to established historical practice, thus maximizing the archival value of the papers. It appears to have worked, for the authors systematically -- and in some cases, apparently, painfully -- searched for old records, letters, and memoranda. The vignettes that surface therefrom are fascinating.

    No one should be surprised that the accounts of the camel (designed by committee) languages, ALGOL 60 and COBOL, have a somewhat different flavor from the others. There is a gold mine for students of decision making processes in this book. The conference organizers are to be commended for providing two accounts of ALGOL 60, one from the American and one from the European point of view. The contrasting perceptions and the almost recursive discussion are both intriguing and delightful.

    This reviewer's one regret is that it was impossible to capture and document the conversations that occurred over the coffee cups and in the corridors. In summary, this is a superb book, a must for all computer professionals. It is also one of the very few records of a conference of any sort where the reader gets a feeling for what it was like to actually be there. This reviewer was there and reading this book almost four years after the conference brought back delightful memories with preternatural clarity.


          in ACM Computing Reviews March 1982 view details
  • Van Deusen, M. review of Wexelblat 1982 view details Abstract: The History of Programming Languages provides a glimpse into the language design process for thirteen important languages. Each language chosen had to have been designed before 1967, to allow historical perspective, and had to still be in use in 1977. The authors were invited because of their central positions in the language design efforts. FORTRAN is described by John Backus, ALGOL by Alan Perlis and Peter Naur, LISP by John McCarthy, COBOL by Jean Sammet, APT by Douglas Ross, JOVIAL by Jules Schwartz, GPSS by Geoffrey Gordon, SIMULA by Kristen Nygaard, JOSS by Charles Baker, BASIC by Thomas Kurtz, PL/I by George Radin, SNOBOL by Ralph Griswold, and APL by Kenneth Iverson. To provide some consistency among so many authors, language coordinators were given the responsibility of providing review and aid to the authors. The result is a work of amazingly high quality.

    The particular interests of the authors show in the variety of organization and emphasis found in the papers. John Backus describes the background of the FORTRAN project, some of the design decisions, the documentation and implementation. Alan Perlis emphasizes the many people involved in the ALGOL design, from before 1958, through the Zurich and Paris meetings, culminating in ALGOL 60. Peter Naur concentrates on the design decisions made between the Zurich and Paris meetings. The disagreements which surface in appendices to his paper make for fascinating reading. Kristen Nygaard describes the many changes which the design of SIMULA went through from 1961 through 1971, from SIMULA I to SIMULA 67.

    The book is not a dry history -- many statements seem particularly surprising in hindsight. John Backus says of FORTRAN, "As far as we were aware, we simply made up the language as we went along. We did not regard language design as a difficult problem, merely a simple prelude to the real work of designing a compiler which could produce efficient programs." Jean Sammet stresses with regard to COBOL, "We were going to recommend a short range composite approach good for at least the next year or two."

    The history of the technical decisions is particularly well researched and presented. Many ideas were taken directly from other languages, such as the separation of the data description and executable statements in COBOL, deriving from FLOW-MATIC. Some seemed to occur almost casually, such as Thomas Kurtz commenting on the design of BASIC, "Around 1960 or 1961, after a visit to the PDP-1 time-shared computer at MIT, I can clearly recall John McCarthy saying, 'Why don't you guys do time sharing?' Shortly afterward I said to Kemeny, 'I think we ought to do time sharing.' Kemeny responded, 'OK.' And that was that!" Other decisions stemmed from deadlocks, as Alan Perlis described, when a European member of the ALGOL committee declared "No! I will never use a period for a decimal point." The proposal from Joseph Wegstein for three levels of language calmed the situation. The ALGOL paper and appendices by Peter Naur present different views of the same experience. Even a project consisting of only two people can produce its share of excitement. Kristen Nygaard describes the shock of a switchboard operator at overhearing a violent argument between two men in a hallway. She was reassured that it was just Dahl and Nygaard discussing SIMULA.

    One thing which emerges from many of the papers is the deep involvement which a language design can elicit from its designers. John Backus and Jean Sammet both describe many late, long hours.

    But this book is not just a series of papers by knowledgeable authors. It is itself a history of the History of Programming Languages Conference held in Los Angeles in 1978. Jean Sammet, the General Chairman, describes how the conference was put together. There are many valuable ideas here for potential conference organizers. The Conference Historian, Henry Tropp, provides a historical perspective and suggests archiving of design papers. The keynote address is by Grace Hopper. Its transcript captures the qualities of innovation and humor which make her talks such an experience. The author talks are based on the papers, so there is much redundancy of material. The main value to be gained by the duplication is the opportunity to discover the human side of the authors, which comes out in the more informal relation to the audience. Jean Sammet brings down the house with her lament that students are not given more than a passing exposure to COBOL before they receive their degrees in computer science.

    The question and answer sessions were often as interesting as the talks. The book gives John Backus's answer to the question why the letters I through N were chosen to designate integers. The readability of these sections attest to the effort which Richard Wexelblat put into the editing of this volume. The History of Languages represents a tremendous amount of effort from a great many people, and is a book which programmers as well as language designers will find both instructive and enjoyable.
          in ACM Computing Reviews March 1982 view details
  • Gifford, S :Summary of The Development of JOVIAL" view details Extract: Summary of presentation

    Summary of The Development of JOVIAL


    Solomon S. Gifford

    Con Rodi


    CS 5314


    Beginnings


    In late 1958, the ACM published a description of the International Algebraic Language (IAL, now called ALGOL), and the Air Force launched a large command and control system called SACCS. SAGE, the largest real-time system to date, had just been completed in assembly language. It and IAL served as the basis for the new programming language JOVIAL. Jules I. Schwartz and others recommended to develop a high-level language to build SACCS. Schwartz wrote that the Development of JOVIAL to serve as a “sort of permanent record of the language.” Though not developed singly by Schwartz,  the language is named after him. OVIAL, or “Our Version of the International Algebraic Language” had a connotation to the birthing process, so it was renamed JOVIAL, or “Jules’ Own Version of the International Algebraic Language” during its early stages of development.


    The language was designed in parallel to its two compilers, the AW/FS Q-31 and 709, since the emphasis on the language was to develop the compilers for use for the SACCS development. The compilers themselves were written in JOVIAL (The first JOVIAL compilers may have been the first compilers written in the language they where to compile.) Documentation for the language was not published until after major portions of the compilers were written.Versions include J0, J-1, J1, J2, J3, and later J3B, J4, J5, J5.2. Other experimental versions where JX2, Basic JOVIAL, JX2, and TINT. CORAL, SYMPL, SPL, CMS II and perhaps PL/I were influenced by the language. Finally, in 1973, a new standard version (J73) was produced, the version that is still in use today.

    Objectives


    The original major objective for JOVIAL was to use it for programming large systems. This required a flexible language.  Things ignored were compiler speed, language elegance, and standardization. This was a direct result of the fact that language features were added as needs were realized.In fact, the paper gives the example that the Data Definition capability was designed in 30 minutes.Originally I/O and exception handling were left out of the language. I/O was added later as subroutines.


    Most of the major language features were taken from IAL.This included syntax; compound statements; major operators; statement structure, labeling and ending; procedure calls, and loop structures. There were a few major additions or changes.The first is the Data Definition area.The lowest data description level is the item.This could be one of multiple types (floating point, fixed point, character strings, and status values). Groups of items were placed in an entry, an abstraction of a particular object (a Person for example).Entries then were put into tables, the highest level of object abstraction.This was set up to define data structures and to achieve the capability of access to the data without having to know where the data was kept in the items and entries. Therefore, changes could be made in the data description independent of the JOVIAL program, for the most part.


    Another major feature is access to bits and bytes of items (keywords BIT and BYTE) and access to entries in tables. With the LOC keyword, a table or item can be referenced, similar to pointers in modern languages.With this the designers also added the capability to insert machine language into a program through the keywords DIRECT &lt;machine language&gt; JOVIAL.

    Conclusions


    As stated earlier, many of the design decisions for language features where made as they were needed. This resulted in a sometimes-awkward syntax.&nbsp; Since there were no tutorials made, the language was hard to learn, but once beginners learned the language, they hardly had any questions because the language was practical.


    JOVIAL was originally intended to be written on one computer and run on many different computers, but as time went on, many of the compilers were written to take advantage of the computer it was written on, leading to many incompatibilities and subsets of JOVIAL. The flexibility and generality of the language led to a move away from portability. JOVIAL met its objectives as exemplified by the many systems produced in the language (even still today) by the FAA, Air Force, Navy, and others.


    Bibliography


    Schwartz, Jules I. "The Development of JOVIAL." SIGPLAN Notices
    13.8 (1978): 203-214.  

    Extract: Summary

          in ACM Computing Reviews March 1982 view details
  • Bellec, Jean "from GECOS to GCOS8 an history of Large Systems in GE, Honeywell, NEC and Bull - a view by Jean Bellec (FEB), from the other side of the Atlantic:" July 2001 view details External link: online
          in ACM Computing Reviews March 1982 view details
    Resources