N1(ID:1663/n::002)

Olivetti's non-procedural language 

for Non-procedural-1

Early non-procedural and rudimentarily functional language for the Olivetti ELEA 9003

Pacelli and Palermo  Olivetti, 1959
Places
Related languages
Church typed-lambda calculus => N1   Incorporated some features of
N1 => ABL   Evolution of
References:
  • Lombardi, Lionello "A general business-oriented language based on decision expressions" view details Extract: Introduction
    The methods presented here grew as the applied facet of an operational theory of files [9], under study and development since 1959. Such a theory aims at the formulation of models (or sets of postulates) of file processes built by analyzing the way such processes actually are programmed for computers. The first such model is currently being implemented at Olivetti as "N1" (Non-procedural-i) language? Here, highlights of some of its aspects are given. However, this presentation refers only to the aspects relevant to sequential or collinear file processing (thus referring to card I-O, magnetic tape, printers and disk files used sequentially), without describing how tables and arrays are handled. Nevertheless, although not discussed here, N1 also handles random access tables and arrays by table functions in a way described in [10, Sec. 2] and [13].
    This N1 language is nonprocedural -- in the sense that the actions to be taken are not stated but are performed according to a universal record-processing procedure routine or "machine" whose operation is described later in this report. The language consists of control expressions, some of which can be regarded as decision predicates (as opposed to explicit decision tables). There are eight kinds of such expressions, which are put together to build a program and presented for compilation in an arbitrary order. The universal routine or skeleton built into the compiler should be viewed as a version of the set of postulates of the underlying theory. Since the theory is still in an experimental state, it may still be extended (and already has been extended several times) to better cover its functional scope.
    As far as the grammar of the language is concerned, the only specific requirements to build expressions describing processes are the standard arithmetic ( + , - , etc.) and propositional (AND, OR, NOT, etc.) connectives and the conditional function
    if p then a else b
    which can be stated more compactly as
    a{b}p
    Here a, b and p are forms, and in particular p is a predicate (i.e. a form whose value is either r (for true) or (for false). The function takes the value of a or that of b, depending on whether the value of p is r or ¢. Its purpose is to represent decisions which require structurally different formalizations for different values of the data.
    [...]
    The model has been presented so far in terms of algorithms which can be readily instrumented on any conventional computer. To program any particular collinear file process for a conventional computer for which this model is instrumented one has simply to list the following items:
    (i) a data format description of all the records of all files and of the intermediate variables (which can be given according to the formats of any of the standard business programming languages, with the addition of the key layout description of each input file)
    (ii) the priority order of the input files
    (iii) the identification predicate of each input file
    (iv) the initial values of the intermediate variables
    (v) the list of all intermediate variable declarations, one per intermediate variable
    (vi) the list of all flow control predicates, one or more for each output file
    (vii) the list of all field declarations for the fields of the output files
    (viii) the assignment of the files to input-output devices, that is, the grouping of files into bundles.
    These are, in essence, the principles underlying the experimental business programming language N1 currently in the process of being instrumented on the Olivetti ELEA 9003 computer. Practical considerations have suggested the introduction into N1 of a few more indicators in addition to those discussed here; the most important, perhaps, are two free indicators, called start and stop, respectively, which are not associated to any particular file, which by having the value r denote the first and last pulse of a process, respectively. These additional indicators are handy to represent the processing of nonstandard opening and closing labels of files.
    Any collinear file process is represented in N1 simply by writing items i-viii. In particular, the N1 programmer is completely relieved of any concern about key comparison and logic and input traffic regulation. I t is well known that these are the main kinds of burdens of representing collinear file processes in conventional or procedural languages, especially when processes are highly parallel, that is, are designed to handle numerous output files at the same time. The fact that N1 moves these burdens from the human representation of each process to the automatic model, probably explains the fact that N1 process representations are often of an order of magnitude shorter than the corresponding ones in conventional procedural languages. However, this is only a side issue, since the main motivation in working out N1 was not to achieve conciseness, but to have a language in which local corrections, changes or extensions of any process can be performed by acting locally on its representation, without risking unpredictable and hence undesirable side effects on other parts of the process. This is easily achieved in N1, since each single line of the process representation is largely self-contained in the sense that it only and completely represents one of the facets of the process, and by and large can be modified without concern for the others.
    Abstract: The structure of a digital computer programming language which covers a wide class of business and file processing applications is presented. Such a structure, based on identifying and incorporating into a compiler the aspects common to all processes of such class, permits writing extremely compact programs, even for comparatively complex applications, in terms of tables of control expressions which express only information characteristic of the particular application. Furthermore, local changes of a process (e.g. changes affecting only one of the output files involved) can be effected by local modifications in the program (e.g. modification of only one entry of the tables). This structure also allows for inexpensive preparation of loading-speed compilers which translate the source programs into efficient machine codes. The approach adopted here departs from conventional mechanical language design philosophies. It stresses the structural analysis of the class of processes to be represented in the languages, as opposed to emphasizing formal (i.e., contents-independent) syntactical definitions. It relies exclusively on nonprocedural representation of processes as sets (tables) of relations between data and results (there are no control statements such as GO TO, etc.), instead of using procedure descriptions (which are one-to-one translations of flowcharts). Here an invariant pattern of procedure is identified as characteristic of the class of all batch file processes.
          in [ACM] CACM 7(02) (Feb 1964) includes Papers presented at a Working Conference on Mechanical Language Structures, Princeton, N. J., August 1963 view details