FOIL(ID:325/foi001)File Oriented Interpretive Language. CAI language. Samples: References: INTRODUCTION In the summer of 1967 a project was begun at The University of Michigan to provide users of a general-purpose, time-sharing system with the capability for exploring conversational uses of computers for instruction. The idea for the project developed from the interest of faculty members in a number of subject areas who wished to develop conversational programs and investigate the benefits of computer-assisted instruction in the classroom and laboratory using existing time-sharing facilities. Support was provided by UNIVAC Division of Sperry Rand Corporation. A general-purpose system is appropriate for application of computers to college-level instruction. The computer is available for small projects requiring one or a few terminals for which the acquisition of a dedicated system with many terminals is not justified. Some instructional applications take advantage of existing system routines by incorporating them as subroutines. Other lessons are variations of computer programs written for scientific research purposes. Students obtain additional benefits by learning computer skills and developing interests in other computer applications which can be pursued on the general-purpose system. Familiar translators in general-purpose systems provide considerable computational and logical capability immediately. Subroutines were written in FORTRAN to add convenient response processing operations and other desired functions to the existing language. In this way the capability for describing instructional lessons was improved promptly and with a minimum investment in system programming. However, existing languages intended for algebraic computation or symbol manipulation are not ideally suited for most instructional applications for the following reasons.
A special-purpose, instructional language which is easy to learn and convenient to use is necessary to encourage nonprogrammers (subject experts and educational technologists) to participate in the specification and development of instructional programs. Although valuable information on desirable characteristics for an instructional language was extracted from previous experience with COURSEWRITER, 1 PLANIT 2 and other systems, the available computer-assisted instruction (CAI) languages were not found suitable for the variety of research and lesson development anticipated. Except for LYRIC a which uses a pre-compiler translator written in FORTRAN, CAI languages are generally implemented for a particular computer and are unavailable on other systems except by extensive reprogramming. Lesson authors place various demands on a language and new characteristics are continually being identified and developed. While some users could work within the frame-structure restraints of PLANIT or the limited computational capability of COURSEWRITER, others found these teatures unacceptable and desired a language which could be more easily adapted to their individual needs. Extract: Rationale for an Interpretive Language RATIONALE FOR AN INTERPRETIVE LANGUAGE FOIL (File-Oriented Interpretive Language) was developed to provide conversational lesson-writing capability for potential instructional programmers who have access to a general-purpose, time-sharing system. Programs written in FOIL reside on direct-access files and are processed by an interpreter written in FORTRAN. The interpretive mode places few constraints on the syntax of the language and a number of beneficial features are achieved. FOIL programs are easily modified and revised. A convenient test editor, available on most general-purpose systems, is used when major revisions of the lesson are to be made. However, many errors detected by the lesson author while testing the program are corrected during execution without returning to the operating system. The lesson author simply replaces the line of the lesson containing an error by the corrected statement and execution continues. The interpretive mode also eliminates the need for separate translation or compilation of programs prior to execution. During lesson operation statements can be entered directly from the terminal with a one-character prefix which causes immediate interpretation and execution. Additional conveniences resulted from coding the interpreter in FORTRAN. An executable version of the interpreter was available shortly after the project began. Revision of the language and addition of new features and operators is quite convenient; a number of variations of the processor have been prepared. Access to other system software is achieved by providing the interpreter with linkage to existing subroutines. The source code for the processor is relatively machine independent and therefore easily adapted to other time-sharing systems. FOIL was originally implemented on an IBM 360/67 computer operating under the Michigan Terminal System. James Ruddell at the University of Maryland readily adapted the processor for the UNIVAC 1108 system and added capability for lesson building and editing. FOCAL at the Ontario Institute for studies in Education and a similar processor under development at the University of Minnesota are two additional interpreters written in FORTRAN which provide lesson-preparation capability to users of a general-purpose, time-sharing system. Extract: Description of FOIL DESCRIPTION OF FOIL Programs written in FOIL consist of a series of commands or imperative statements. The statements instruct the FOIL interpreter to present information and questions to students, accept and process typed responses from the students and react appropriately by branching to new segments of the program, performing calculations, or compiling data on the students' performances. A Simple illustration. The following seven statements from a FOIL program provide for the presentation of a single question to a student and a response to his answer. TY EXERCISE? ACCEPT IF 'NO,' GO TO FINISH IF 'YES, OK' NUM = NUM + 1 GO TO NEXT GO BACK PLEASE ANSWER WOULD YOU LIKE TO CONTINUE THE YES OR NC The TY or type statement causes the FOIL interpreter to type WOULD YOU LIKE TO CONTINUE THE EXERCISE? to the student. A string of characters is then accepted from the student (as indicated by the ACCEPT statement) and retained in a buffer for processing. If the buffer contains NO, control is transferred to a statement labeled FINISH (elsewhere in the program, but not shown in the example). Single quotes around the word NO indicate that it is a keyword for which FOIL searches in the student's response. Any answer containing NO is treated as a negative reply from the student and causes a branch to FINISH. A set of keywords which the interpreter is to treat as equivalent is written separated by commas, between single quotes. All student-responses containing any one of the equivalent keywords are treated the same. In this example, YES and OK are equivalent keywords. A student's answer containing either word causes the two statements following IF 'YES, OK' to be executed. The statements are indented one or two spaces to indicate the scope of the conditional. NUM = NUM + 1 causes one to be added to the variable called NUM. All variables are assumed to be integers and are preset to the value zero. Any algebraic expression can be evaluated by integer arithmetic in the assign statement. After NUM is incremented, a branch is executed to a statement labeled NEXT (not shown in this example). A student's answer containine neither NO, YES, nor OK is unrecognized. This situation causes the message PLEASE ANSWER YES OR NO to be presented to the student just before a branch is executed back to the ACCEPT statement to wait for a new answer. Any message following a GO statement is presented to the student just before the branch is executed. Thus, the last statement in the example is equivalent to the following pair of statements: TY PLEASE ANSWER YES OR NO GO BACK Type and branch statements occur together often in FOIL lessons and some authors find it convenient to combine these into one statement. BACK is a predefined variable which always refers to the previously executed ACCEPT statement. It eliminates the need for labeling every ACCEPT. Additional predefined variables (not shown in this example) enable convenient branching to other unlabeled points in a lesson. GO ON causes a branch to the next major segment of the lesson. GO TO HERE + 5 initiates a branch five statements ahead of the current statement. [...] When a STOP statement is encountered, execution of a program terminates. [...] Additional types of anticipated responses used in the IF statement are available. An anticipated response in quotation marks (e.g., "GENERATIVE GRAMMAR") is matched by a student's response only if it consists of exactly the same characters, including spacing and punctuation. A digit following a list of keywords (e.g., 'MEAN, MEDIAN, MODE, AVERAGE'3) indicates that the student's response must contain more than one (in this case, three or more) of the keywords to constitute a match. A percentage comparison, useful for allowing some spelling errors, is indicated by percent signs followed by an appropriate number. For example the anticipated response %SCHAUMGUMMI%70 will successfully match a student's response if 70 percent or more of the letters are present in the appropriate order. Existing computer programs or procedures requiring extensive computation have been assembled or compiled as subroutines and incorporated in the FOIL interpreter. A statement in the lesson such as CALL SUB(X,Y,Z) initiates the subroutine computations. Two predefined variables are available for timing a student and making decisions on the basis of his progress. The value of TIME is the number of minutes since the student began the lesson; RPTIME is the student's previous response time in seconds. TIME is updated by the system clock and RPTIME is automatically set each time the student completes a response. Each student's progress through a lesson is automatically recorded on a temporary data file which can be listed or copied to a permanent file after completion of the lesson if the information is of interest to the author. The data file contains records for study of responses which were not recognized, response times, etc. in Proceedings of the 23rd ACM national conference January 1968 view details FOIL, a programmed at The University of Michigan, is an experimental language which has added some of the convenience factors of MENTOR to a combination of FORTRAN and COURSEWRITER. It has been used for dialogues similar to those programmed with ELIZA and MENTOR. MINORCA is being revised to provide greater capability for programming interaction with a student seeking information needed for vocational decisions. The designers intend to provide much of the string-processing capability of ELIZA and the provision for moving from one context (or "script") to another. [...] A File-Oriented Interpretive Language (FOIL) 14 provides a convenient format for inexperienced computer users, with a special advantage over FORTRAN when describing input and output. The program requires little space in core since most of the text resides on disk or other peripheral storage until it is called on by the interpreter. The translator has evolved during a program of exploration of language characteristics; it has also been implemented by the staff at the Uni- versity of Maryland on a Univac 1108. [...] in Morrell, A. J. H. (Ed.): Information Processing 68, Proceedings of IFIP Congress 1968, Edinburgh, UK, 5-10 August 1968 view details in ACM Computing Reviews 15(04) April 1974 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 ACM Computing Reviews 15(04) April 1974 view details in SIGPLAN Notices 13(11) Nov 1978 view details |