SEL(ID:567/sel001)for Self-Extensible Language Istituto di Elaborazione della Informazione, CNR, Pisa, Italy Samples: References: Introduction One of the classic ideas for resolving the problem due to programming language proliferation, is to design a universal language. However, until now, although the new 'universal' languages have contributed to clarify many problems, they have complicated many others. We don't expect these difficulties to be completely resolved by the previously conceived selfextensibility as, e.g. ALGOL 68, STMULA 67, etc. for the following reasons : 1. These universal languages are high level languages. They require a rather complex compiling system which excludes them from the field of small computers. 2. They have an initially defined syntax which, although extensible, binds the system to remain syntax directed. It is not certain that this is the most natural way of describing programming systems, e.g. an operating system. 3. There is no possibility to introduce new basic concepts into the language (e.g. in case of hardware modification) without a drastic modification of the compiling system. 4. There is no possibility to extend the language to make it formally equivalent to other, already existing, languages, e.g. FORTRAN, ALGOL 60, etc. 5. While there is, in these languages, a general method of compiling, this method cannot be as efficient as the particular one, made for one language. We consider the most serious restrictions to be points (3) and (4). In designing SEL, we have taken account of the above criteria. Therefore, SEL is not a high level language, it doesn't use a syntax recompiling mechanism as a built-in facility. Selfextension is procedural, not declarative, so, SEL is also a metalanguage for its own extension. A 'piece of program' can be not only a building element for a further extension but also an operative tool for doing it. The freedom of choosing symbols for denoting new concepts allows the system to describe conventional programming languages in their own syntactic form. Particular care has been taken on efficiency. External link: Some remarks on terms used Extract: Some remarks on terms used Some remarks on terms used 2.1. The term language is used for denoting a tool for manmachine communication which doesn't imply previous grammar definition. 2.2. By extensibility we denote the capacity to alter the meaning of a message expressed in the language, or make pragmatically interpretable other messages which were not such before. The term self-extensibility will be used to indicate the possibility of extending a language by means of a program written in the same language. Self-extensibility we shall call also vertical extensibility in order to distinguish it from the possibility of introducing new basic concepts in the language (by modifying its basic implementation) which we shall call horizontal extensibility. 2.3. The basic elements of the external representation of a SEL program, i.e. those of its text, are names (words), in agreement with the preference that human beings show towards a text taken as a sequence of words rather than as a sequence of characters. Normally, a man is in fact able to single out a word without necessarily knowing its meaning. 2.4. In a text a name has two attributes: (i) the occurrence which is its position in the text and (ii) its meaning which is a reference to some physical objects (values) denoted by it. 2.5. A text of a program-although it may have a meaningdoes nothing: it is just a declaration. For associating an action with a text we have to define what we want the program to do. The dejinition of a program is a mapping of the text into actions. Before executing it, we have to generate the program according to its definition. The generated program can then be executed or, generally speaking, applied. Finally, a program can be deleted. Extract: Basic concepts of SEL Basic concepts of SEL SEL is self-extensible vertically but, as its structure also facilitates horizontal extensibility, it is to be considered as a general method for building programming systems rather than building a well defined language. The basic instructions presented in this paper are just some examples, and are by no means suggested as an optimal choice. 3.1. A SEL program is an ordered set of objects. An object is composed of two parts: an external object which is the name of the object, and an internal one which is its value. By convention, a SEL object always has two values: an executable one, i.e. aprocedure, and a static one of some type (e.g. integer, real, etc.). One of the basic ideas of SEL is just this active feature of its 'words', i.e. the fact that each object (its procedure) can be executed. To extend this ability to all names, we introduce the convention that to each object not otherwise defined 'belongs' an error message procedure. The internal part of an object can be redefined by applying (executing) other suitable objects (i.e. their procedure). The result of the application of an object is completely defined by : 1. The name of the object (a) its occurrence by which the object is actually entered external object (b) the meaning of the object (the reference to the value of the object). 2. The value of the object (a) procedure internal object (b) static value. 3.2. It is a consequence of what was said before that the definition of a SEL program, i.e. the mapping of words into actions is the simplest one-to-one correspondence between external and internal objects. It follows that any arbitrary sequence of SEL words is a formally correct SEL program. Pragmatic errors must be controlled by the program itself, so any 'error message' is to be considered as a result of an execution, not just a message from a supervisor program. 3.3. The name of an object is singled out from the input character string without taking into consideration its meaning. There is a iixed convention for the inner syntax of words, which cannot be altered by any self-extension. (Although it could be modified by a horizontal extension.) In our implemented version the SEL system recognises identifiers, integer constants, real constants, string constants (all of which are defined as in ALGOL) as well as an additional class of special identifiers and one of special characters. 3.4. SEL has a basic object set (basic vocabulary). The procedures of the basic objects represent the basic actions of SEL. Moreover, each basic object can generate a new internal object (see Section 3.8) which (or a combination of some new internal objects) can be assigned to an external object. Object generation is the main facility of self-extensibility in SEL. 3.5. An object (i.e. its procedure) can operate both on its own value and on the ones belonging to other objects, i.e. its parameter can be either itself or another object. As for the basic vocabulary, for the sake of simplicity, we assume that if a procedure has one parameter other than itself, this parameter is the object whose occurrence is successive to the occurrence by which the procedure was entered. For example, if the symbol $PSB has the procedure which prints out the name of a word, the execution of $PSB APPLE will cause the print out of the symbol APPLE. Similarly, if a basic procedure has more than one parameter, these parameters are the objects whose occurrences are successive to the ones by which the procedure was entered. For example the execution of $SUM A B C assigns the sum of the static values of A and B to C if A, B and C are defined as possessing integer values (see Sections 4.1 and 4.5.). Parameter evaluation takes part of the procedures of the basic SEL objects by using a system vector (called the occurrence vector) which contains the external representation of the SEL program in form of pointers to object names. Names contain (point to) values. 3.6. Macros can be easily defined in SEL: an ordered set of objects can be considered as one internal object and can be assigned to another external object. One can do this by applying some basic objects (i.e. executing their procedures). E.g. <* $PSB APPLE * > + Y assigns the sequence of objects '$PSB APPLE' to the external object having the name Y. The procedure of the object denoted by the name '<*' defines a macro, i.e. a compound object consists of sequence of objects whose names follow the '<*' until '*>'. The next object to be executed is that following '*>', in this case '+' whose procedure assigns the macro defined to that external object whose name follows it, i.e. to 'Y'. Formally, a symbol which denotes a macro is intended to be substituted statically by the sequence of symbols closed between 'c*a'n d '*>'. When the macro is defined as in the above example, any execution of the procedure of the object 'Y' produces the print out of 'APPLE'. In SEL a defined macro can be executed immediately like a subroutine (as in the above example) or can be generated as a real macro (see Section 3.8). 3.7. Macros may have formal parameters. One way of introducing this is by using an object which is also a macro. Another way of introducing this is by using references, which are a type of value. A particular object, $ADR has the procedure which, executed, defines its successor as possessing a reference. Another procedure (that of $ASR) can assign a value to it. E.g. executing assigns a value to R which is a reference to Q. A particular object denoted by '$REF' is a formal parameter object. Its internal object, the value of the parameter, is the one to which the successor refers. With the above reference definition the execution of the SEL program will cause the print out of 'Q'. There are two system references accessible to the user: $THS and $SUC. The value of $THS is the reference to the symbol to which belongs the macro under execution. E.g. if after the definition one executes T, it produces the print-out of its own symbol, i.e. T. Similarly $SUC has the value which is a reference to the symbol whose occurrence is successive to the occurrence of the symbol referred by $THS, by which the macro was called. E.g. after the definition if one calls the macro by the occurrence of T in the sequence . . . T W . . . , it produces the print-out of W. Two particular words $NXT and $PRV can cause to move forewards or backwards respectively the system pointer which indicates the occurrence of the symbol pointed out by $SUC (altering, in such a way also the value of $SUC). This makes possible a look-up from a macro to the 'defining' level. 3.8. The SEL system is always in one of two states: interpretation or generation. If the state is interpretation when, by its occurrence, a basic object is entered, the procedure is executed; while, if the state is generation, a new similar procedure is generated. Particular objects having the name '<:' and ':>' can switch the state of SEL from interpretation to generation or vice versa respectively. Therefore, executing <: $PSB APPLE :> -t X doesn't cause any print out, but entering an occurrence of X after this definition, will result in the print-out of APPLE. (The same symbol '+' could be used for assigning either a macro definition or a macro generation.) A generated macro can have formal parameters as in the case of macro definition. The main difference between the execution of a macro definition and that of a generated macro is that the latter is an optimised procedure while the former is a sequence of calls of distinct procedures under the supervisor SEL system. Note that a macro generated has no internal definition; the entering of the occurrence of the symbol which denotes it will cause the execution of the procedure independently from the state of SEL. Extract: Some typical instructions of SEL 4. Some typical instructions of SEL 4.1. Any symbol can be defined as possessing a value of some type (either variable or constant, see also Section 4.5). The words $ADR, $BOL, $INT, $REL, and $CHR define their successor as possessing reference, Boolean, integer, real and character values. Vectors and structured values can be introduced by field generation and references. On each type of value there are defined some elementary operations: as arithmetic, Boolean operations, assignments of various types, etc. 4.2. The whole program written in SEL is intended to be included between two conventional words: $PRP and $SYS. $PRP initially has no procedure, but the user can generate and assign one to it. So each, execution may begin with a user defined preprocessing. $SYS ends the program execution and, when a conversational version of SEL is available, returns the control to the user. The procedure of the word $PGO assigns the Boolean value true to its successor if $SUC has no meaning (it points out of the program). Obviously, it has a practical meaning only internally to a generated procedure. 4.3. The procedure of $SKP causes its successor to skip. If the successive symbol denotes a macro of symbols, then the execution of $SKP causes the whole macro to skip. The words $SKT and $SKF cause their second successor to skip if the value of their first successor is Boolean, respectively true or false. 4.4. The word $RET causes a return from the execution either of a macro of words or of a procedure. $REP causes the repetition of the execution of either a group or a procedure. 4.5. A word can represent either a variable or a constant. By means of the execution of explicit instructions $VAR or $CST one can change the state of a symbol into a variable or into a constant respectively. Executing $CCB assigns the Boolean value true to its second successor if its first successor is a constant, false otherwise. E.g. '+' has the procedure to assign the last defined group or generated procedure to its successor. After the execution of <* $PSB 'CONSTANT ERROR' $SYS *> - ERC \EXECUTING ERC IT GIVES AN ERROR MESSAGE AND ENDS THE PROGRAM\ <: $CCB $REF $SUC B $SKF B ERC - $REF $SUC $NXT : > ++ \IF THE SUCCESSOR OF THE CALLING SYMBOL (OF THE SAME '+') IS NOT A CONSTANT, IT ASSIGNS THE LAST GENERATED PROCEDURE OR GROUP TO THIS SUCCESSOR I.E. IT DOES THE SAME AS BEFORE SAVE THE CONTROL ON CONSTANTS. B IS A BOOLEAN VARIABLE\ no new symbol group or procedure can be ssigned to a constant. 4.6. The word $LAB defines its successor as a label pointing to the present occurrence of the symbol referred to by $SUC. The execution of a label consists in the transfer of the control to the occurrence denoted by the label. E.g. if we wish to define as label any word having an occurrence followed by ':'; pointing to the successor of the same occurrence, we can define the following preprocessor : $ADR SYM \DEFINES SYM AS POSSESSING A REFERENCE. AS IT IS NOT DEFINED AS A CONSTANT, IT IS A VARIABLE\, <* $NXT $LAB $REF SYM *> + LB \THE MACRO DENOTED BY LB ADVANCES THE SUCCESSOR WHICH THE PROCEDURE BELONGS TO AND DEFINES THE SYMBOL REFERRED BY SYM AS A LABEL DENOTING THE PRESENT OCCURRENCE OF THE SUCCESSIVE SYMBOL\ <: $ASA $SUC SYM $NXT \ASSIGNS THE REFERENCE VALUE OF $SUC TO SYM AND ADVANCES $SUC\ $CPS $REF $SUC : B \COMPARES THE SYMBOL REFERRED BY $SUC WHETHER IT IS A ':'. IF IT IS SO, IT ASSIGNS THE BOOLEAN VALUE TRUE TO B, FALSE OTHERWISE\ $SKF B LB \SKIP IF THE VALUE OF B IS FALSE, OTHERWISE DEFINE THE LABEL.\ $SPGO B $SKT B $REP :> -. $PRP \CONTROL WHETHER THE WHOLE PROGRAM IS SEARCHED, REPEAT THE PROCEDURE OTHERWISE. ASSIGN THE PROCEDURE TO $PRP\ $CST $PRP \PROTECT $PRP AGAINST CHANGING PROCEDURE\ in The Computer Journal 14(3) May 1971 view details in Computers & Automation 21(6B), 30 Aug 1972 view details 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 Computers & Automation 21(6B), 30 Aug 1972 view details |