SNOBOL4(ID:303/sno005)Classic SNOBOLGriswold et al, 1967. Quite distinct from its predecessors. Unix port of the original macro implementation Declarative with dynamic scope. Patterns are first-class data objects that can be constructed by concatenation and alternation. Success and failure used for flow control. Delayed (unevaluated) expressions can be used to implement recursion. Table data type. Structures: Related languages
References: in Rosen, Saul (ed) Programming Systems & Languages. McGraw Hill, New York, 1967. view details in Rosen, Saul (ed) Programming Systems & Languages. McGraw Hill, New York, 1967. view details in Rosen, Saul (ed) Programming Systems & Languages. McGraw Hill, New York, 1967. view details The SDS 940 SNOBOL4 system will accept programs written in a language which is basically compatible with a subset of Bell Labs' November 22, 1967 version of SNOBOL4. SNOBOL4 is not a superset of SNOBOL3 but is in most ways very similar to SNOBOL3. The major exception is in pattern matching and the pattern datatype. The SNOBOL4 system permits programs to be created, run and debugged interactively. The principal data object in the SNOBOL language is a string of characters. The language permits building up longer strings from shorter strings through concatenations. In addition, through pattern matching, strings can have their contents tested and have the matched substrings assigned to string variables. Other features of the language are arithmetic on integer strings, built-in functions for general use, and programmer defined functions which may have local variables and can be recursive to arbitrary depth. Input-output from files is provided as well as from the teletype. in Rosen, Saul (ed) Programming Systems & Languages. McGraw Hill, New York, 1967. view details in Rosen, Saul (ed) Programming Systems & Languages. McGraw Hill, New York, 1967. view details in [ACM] CACM 12(11) (Nov 1969). view details In general, string processing systems deal with data which is in the form of unstructured strings of characters. COMIT (Yngve, 1962), SNOBOL-3 (Farber, Griswold and Polansky, 1966) and SNOBOL4 (Griswold, Poage and Polansky, 1968) are three well-known string processing languages. Typical of the types of operation possible in these languages are matching, insertion, replacement and concatenation of strings and substrings. With the increasing usage of computers in many different fields, the distinction between numeric and non-numeric applications is becoming less apparent, as for example in information retrieval problems. Consequently it seems desirable that a single programming system should incorporate efficient numeric and non-numeric capabilities. The SP/1 system described here has been designed and implemented as a string processing system embedded in FORTRAN-IV. To avoid adding to the diversity of programming systems already in existence and since SNOBOL is a wellknown language whose syntax is readily adaptable to a FORTRAN environment, the operations provided in SP/I are similar to those available in SNOBOL-3. Unlike, for example DASH (Milner, 1967), which is a string processing extension embedded in ALGOL, SP/1 is both a syntactic and semantic extension to FORTRAN. The string processing statements can be represented by a set of macros which are expanded into FORTRAN statements by a macro generator (Macleod and Pengelly, 1969) prior to compilation. The macros have been designed so that there is a close similarity between the syntax of the corresponding SP/1 and SNOBOL3 statements. For example, the SNOBOL-3 statement REPEAT E "(" *V* ")" = V /S (REPEAT) deletes all the pairs of left and right parentheses from a string E. The corresponding SP/I statement is In addition, SP/1 provides a data type known as an association which may have a range of alternative values associated with it. This data type is in some ways similar to the pattern type in SNOBOL-IV and the assertion type in AXLE (Cohen and Wegstein, 1965). A further distinctive feature of SP/1 is that strings are stored as sequences of atoms where an atom is the smallest meaningful unit of the string. The size of an atom is determined on input as shown below, but normally an atom may be regarded as a single character symbol or as a group of consecutive alphameric characters. The latter could be the case for example in text processing where one atom would be equivalent to a word of text. This approach allows the processor to operate on strings composed of text words while retaining the capability to manipulate strings of individual symbols where required. This provides faster operation with a considerable saving in storage requirements in the text processing types of applications where the smallest logical unit of information is a word of text. Thus, essentially, there are two modes of operation, character and text, corresponding to the two types of storage. In the current version of SP/1 mixed mode operations are not allowable. The method of string storage, which involves a hash table, is described elsewhere (Macleod, 1969a). Extract: Introduction In general, string processing systems deal with data which is in the form of unstructured strings of characters. COMIT (Yngve, 1962), SNOBOL-3 (Farber, Griswold and Polansky, 1966) and SNOBOL4 (Griswold, Poage and Polansky, 1968) are three well-known string processing languages. Typical of the types of operation possible in these languages are matching, insertion, replacement and concatenation of strings and substrings. With the increasing usage of computers in many different fields, the distinction between numeric and non-numeric applications is becoming less apparent, as for example in information retrieval problems. Consequently it seems desirable that a single programming system should incorporate efficient numeric and non-numeric capabilities. The SP/1 system described here has been designed and implemented as a string processing system embedded in FORTRAN-IV. To avoid adding to the diversity of programming systems already in existence and since SNOBOL is a wellknown language whose syntax is readily adaptable to a FORTRAN environment, the operations provided in SP/I are similar to those available in SNOBOL-3. Unlike, for example DASH (Milner, 1967), which is a string processing extension embedded in ALGOL, SP/1 is both a syntactic and semantic extension to FORTRAN. The string processing statements can be represented by a set of macros which are expanded into FORTRAN statements by a macro generator (Macleod and Pengelly, 1969) prior to compilation. The macros have been designed so that there is a close similarity between the syntax of the corresponding SP/1 and SNOBOL3 statements. For example, the SNOBOL-3 statement REPEAT E "(" *V* ")" = V /S (REPEAT) deletes all the pairs of left and right parentheses from a string E. The corresponding SP/I statement is In addition, SP/1 provides a data type known as an association which may have a range of alternative values associated with it. This data type is in some ways similar to the pattern type in SNOBOL-IV and the assertion type in AXLE (Cohen and Wegstein, 1965). A further distinctive feature of SP/1 is that strings are stored as sequences of atoms where an atom is the smallest meaningful unit of the string. The size of an atom is determined on input as shown below, but normally an atom may be regarded as a single character symbol or as a group of consecutive alphameric characters. The latter could be the case for example in text processing where one atom would be equivalent to a word of text. This approach allows the processor to operate on strings composed of text words while retaining the capability to manipulate strings of individual symbols where required. This provides faster operation with a considerable saving in storage requirements in the text processing types of applications where the smallest logical unit of information is a word of text. Thus, essentially, there are two modes of operation, character and text, corresponding to the two types of storage. In the current version of SP/1 mixed mode operations are not allowable. The method of string storage, which involves a hash table, is described elsewhere (Macleod, 1969a). in The Computer Journal 13(3) view details in The Computer Journal 13(3) view details in The Computer Journal 13(3) view details in [ACM] CACM 15(12) 1972 view details in [ACM] CACM 15(07) (July 1972) view details in ACM Computing Reviews 15(04) April 1974 view details in [ACM SIGACT-SIGPLAN] Proceedings of the ACM Symposium on Principles of Programming Languages, Boston, October 1973. Association for Computing Machinery. view details in Proceedings of the ACM SIGPLAN symposium on Very high level languages, March 28-29, 1974, Santa Monica, California, United States view details in Software — Practice and Experience 5(01) January 1975 view details in Software — Practice and Experience 5(01) January 1975 view details in IEEE Transactions on Software Engineering (TSE) 4(2) 1978 view details in SIGPLAN Notices 13(11) Nov 1978 view details DOI in SIGPLAN Notices 13(11) Nov 1978 view details in RAIRO - Informatique, 15(2) 1981 view details in Computer Languages 13(3-4) view details in Computer Languages 13(1) view details History NODAL was designed in the beginning 70's at CERN in Geneva as a flexible and easy to handle tool for controlling the SPS accelerator. In NODAL features of FOCAL and SNOBOL-4 (with some influence of BASIC) are combined. The first implementation was written in assembler for the NORD-10 minicomputer, now an assembler version for the NORD-100 exists too. Many of these computers are interconnected in a homogeneous network. Each of these nodes may be used to execute NODAL programs whereby exchange of NODAL statements and NODAL data between the different computers is possible. In the control of the new accelerator LEP other processors than for the SPS are used for which the existing assembler implementations of NODAL cannot be adapted easily. Since NODAL was found to be very useful at testing, during running-in and in all situations where flexible response was required, it was desirable to have NODAL also available for LEP. To overcome the limitations of assembler programs when adapting them to different processors it was decided to create a new version, written in a portable language. The choice was MODULA-2, since for this language compilers are available for all computers used. When designing the control system for the new GSI accelerators, the Prozessrechnergruppe was looking for an interpreter for accelerator control. Because of the portability of the new NODAL version it was decided to cooperate with CERN and use NODAL also at GSI. Extract: Characteristics of NODAL Characteristics of NODAL Contrary to other interpreters NODAL is emphasized by the following characteristics: integrated elements for access to equipment, called data-modules. parts of programs can be exported to run on another computer and results of calculations can be received (not implemented in GSI-version). output of programs and data to files (and also to other computers) is formatted uniformly. Thus it is possible to store programs and data in one file. Special features of the MODULA-2 version of NODAL are: The separation into kernel modules (processor independent) and target modules (processor dependent) eases the adaptation to different types of processors. When transferring NODAL to another processor, only the target modules like file input/output, error handling, operating system access etc. have to be modified. Actually modules exist (or are under work) for MC68000, VAX/VMS, VAX/UNIX, NORD-100, LILITH, TMS9900, IBM-PC. Execution is faster than in the previous assembler versions. This is achieved by generating an intermediate code which is used after first execution of a program. Thus lexical and syntax analysis has to be done only once which speeds up repitative parts of NODAL programs. To calculate arithmetic expressions it is planned to install a 'throw-away' compiler. pdf in Computer Languages 13(1) view details in Computer Languages 15(1) view details Many years ago I headed up a COBOL compiler project for NCR for the then-new VRX systems, which included a "COBOL Virtual Machine" object code set. We produced a "tagged architecture" machine COBOL as a low-level machine language. (My thesis research on a SNOBOL machine contributed some features to the product.) I wrote this up in a paper for the 1978 Fall Joint Computer Conference ("The Criterion COBOL Compiler"). It discusses the approach we took and some of the problems we ran into. The compiler itself was relatively straight-forward, much like a text-book example. (The fact that I was teaching compiler construction at San Diego State University at the time may have influenced my approach.) We compiled the DATA DIVISION statements into descriptors which were handled by the runtime firmware. Incidentally, we were one of the first COBOL'74 compilers to go through the Federal COBOL Compiler Validation Service testing. They found only four problems: two console I/O interpretation questions and two incorrect level diagnostics. My COBOL background before coming to the project was one program in a programming languages course. I later wrote a couple of more programs as tests, which made me an expert among most computer scientists! I still have a reading knowledge of the language in Computer Languages 15(1) view details Resources
|