Higher-order Language Research Articles

Object-oriented design

The current software depression is characterized by software that is late, erroneous, and costly. Experience indicates that the application of appropriate design methodolgies, embodied in a high-order language, is appropriate in combatting this depression. In particular, this paper describes an object-oriented design methodology, using Ada as the implementation language.

The Ada Environment: A Perspective

Can the Ada environment meet the goals of the DoD high-order language effort? The approach described here promises to be both practical and cost-effective.

Real-time programming languages

Real-time programs share one or more of the following characteristics: control of external equipment, response to external events, the timing of intervals and the sharing of processing time between multiple tasks. Real-time languages are designed to ease the job of coding, maintaining and documenting such programs. Two traditional contenders in the U.K. have been CORAL 66 and RTL/2. Both were developed to meet genuine applied needs and, despite many differences, they share one surprising feature—the lack of in-built real-time statements. The main aim of the designers was to choose language features that allow the generation of efficient code. Real-time functions are implemented by standard procedures that interface to a run-time operating system. In contrast, other languages have developed as a result of academic interest in the problems of parallel processing. Examples include Concurrent Pascal and Modula which provides general multiprogramming facilities at the language level. It is also possible to bind to hardware interrupts and manipulate hardware device registers directly from within the language. A confluence of these traditions has emerged under the auspices of the U.S. Department of Defence which has sponsored the development of a new high-order language for real-time programming now known as Ada.

Some comments on ADA as a real-time programming language

This note contains comments on some of the aspects of the High Order Language ADA which are relevant to real-time programming. Design as well as implementation issues related to the construction of distributed real-time systems are addressed. The comments contained in this note are based on the ADA report printed in the June 1979 issue of the SIGPLAN Notices.

Benchmarking interactive systems

A methodology for benchmarking dedicated, interactive systems has been developed at The MITRE Corporation. This methodology uses a synthetic program model of the application which runs on the proposed hardware/operating system configurations and is driven by a statistically derived load. System performance is measured by analyzing the synthetic transaction response times. The methodology yields assurances to a buyer that the benchmarked system has at least an a priori defined amount of computer power available for applications-oriented software. This paper examines the methodology and the problems that were encountered and solutions which have been used in calibrating a benchmark model for a specific application. The benchmark was designed to model a large interactive information processing application on a procurement requiring loosely-coupled (no shared memory) multicomputer systems. The model consists of a set of interacting synthetic program cells, each composed of several abstractly defined components. The model is maintained in a very high level language that is automatically translated into a standard High Order Language (typically FORTRAN or COBOL) for delivery to the competing vendors. These delivered model cells contain automatically generated size and time filler code that “calibrate” the cells to consume the appropriate CPU time and memory space as defined by the abstract size units after accounting for each vendor's hardware and proposed system design.

ADA in Process Control

up a validation facility, and the inter, tion to have support facilities in a num, but we deem this to cover the whole range of potential applications for embedded computer systems in civil context: in other words to include also laboratory automation, environment monotoring etc. I suggest to concentrate on three mayor aspects: the ADA-language itself, the administrative environment being set up by the American Dept,of Defense, and the programming support environment as specified in the Stoneman document. A list outlining the topics: for the language we have algorithms, and I/O and tasking (I use the categorization we established in TC3), but also the issue of flexibility of runtime which has not previously been brought into the ADA-requirements, but it is a topic of interest. On the administrative section there is the issue of standardization which the American High Order Language Working Group has been considering, planning to bring them to ANSI and ISO; there is the plan of set Elzer: I have been following the development of the ADA language since 1975, its very first beginnings. ADA, or the DOD-language, as called at that time was the source of very great hopes; it remains to be seen whether it will fulfill these hopes. One hope was that it would end proliferation. In the area of process control we have at least as many languages as we have in data processing, although our commercial room is much smaller. So some people think that this language will work in some integrating way by sheer economic power. Another great hope was that the language would help in improving programming. Now, improving has always two sides: one is simply technical quality (engineering beauty for insiders), another is to make things simpler. I personally think that ADA may well help in improving the state of the art in a sense to make certain things possible or more elegant, but it will certainly not make things ,_ simpler. My time I worked with the ADA-

Enhanced computer reliability for nuclear power applications

Reactor operator assistance and augmentation by on-line digital computers will improve power reactor safety. To function in this expanded role, the computers must be both extremely reliable and failsafe. Topics in computer and software reliability are discussed, and it is pointed out that all of these error-extinguishing characteristics are available today in general-purpose equipment built for the military. Tactical military computers, peripheral equipment, and high-order languages have the refinements necessary for safety-related reactor control room operations.

Story comprehension and recall in dyslexic students

This article is an extension of work reported earlier in this journal (Weaver 1978). In that paper, we echoed the commonly suggested need for examining reading difficulties in relation to higher-order language processes and offered a schema-theoretical framework for guiding such an examination. In this article we report the findings and implications of an empirical investigation into the characteristics of story recall abilities in students with dyslexia or severe reading disabilities.

Defining general structures.

0 Introduction Henkin demonstrated in [7] that an adequate semantic theory for any axiomatic higher-order functional calculi could be developed, if the class of structures (viz., models, interpretations, realizations, etc.) upon which the semantic theory is based is significantly wider than the class of all standard structures. Moreover, if the calculus contains the axiom schemas of Extensionality and Comprehension, then it is obvious that the members of the appropriate wider class of structures, which may be called the class of general structures, must exhibit a rather high degree of internal organization. In [9], p. 324, Henkin observed that an important technical problem had remained unsolved, i.e., to give a perspicuous definition of this class of structures which is not overly dependent upon the syntactic design of the higher-order language. Andrews proposed one solution to this problem in [1] and [2]; he proved that every general structure must be closed with respect to certain combinatory operators. In this paper I will propose an alternative solution in which the definition of the class of general structures is given in strictly set-theoretical terms. Specifically, I will prove that every general structure must be closed with respect to a family of Projectiυe operations, cf. Kuratowski and Mostowski [10], pp. 357-358, and a Cut operation, which I have adapted from Shoenfield [12], p. 230.

The Cloze Procedure and Proficiency in English as a Foreign Language

The cloze test has received considerable attention in recent years from testers and teachers of English as a foreign language, and is becoming more widely used in language tests, both in the classroom and in standardized tests. However, most of the research has been carried out with native speakers of English and the results do not produce clear-cut evidence that the cloze test is a valid test of reading comprehension. The article reports on a series of experiments carried out on the cloze procedure where the variables of text difficulty, scoring procedure and deletion frequency were systematically varied and that variation examined for its effect on the relationship of the cloze test to measures of proficiency in English as a Foreign Language. Previous assumptions about what the cloze procedure tests are questioned and it is suggested that cloze tests are not suitable tests of higher-order language skills, but can provide a measure of lower-order core proficiency. Testers and teachers should not assume that the procedure will produce automatically valid tests of proficiency in English as a Foreign Language.

Simulating modular microcomputers

Detailed logic design followed by breakboarding of microprocessor-based systems makes development costly. This paper reports on the use of a high-order language for designing simulation models of microcomputer functional elements ("macromodules") at the register level and for verifying the timing and interface requirements for a family of microcomputer configura tions. The definitions of these microcomputer macro modules (i.e., microprocessors, memories, and input/ output interface modules) was derived in previous system analyses and simulation work reported in References 1 through 5, which were sponsored by the Office of Naval Research. Of the several simulation or emulation methods avail able for studying the design of computer architecture, the technique adopted here provides the level of simulation required to verify timing, interface logic, and data flow within and between macromodules in the family for subsequent simulations of system performance. Furthermore, module-level simulation using discrete logic forms the necessary link between system design and the ultimate description of hardware for a low cost, step-by-step design process. Writing and executing the module simulation programs provides a disciplined approach to hardware design, since the components have to be modeled in detail to follow the flow of data and timing in a microcomputer. The modeling was done in a register-transfer language called Computer Design Language, which is very con venient for this kind of simulation model. Examples of programs in CDL are included.

A high order language optimal execution processor

Article Free Access Share on A high order language optimal execution processor: <u>F</u>ast <u>I</u>ntent <u>R</u>ecognition <u>S</u>ys<u>t</u>em (FIRST) Authors: S. C. Schroeder Litton Industries, Inc., Van Nuys, Calif. Litton Industries, Inc., Van Nuys, Calif.View Profile , L. E. Vaughn Litton Industries, Inc., Van Nuys, Calif. Litton Industries, Inc., Van Nuys, Calif.View Profile Authors Info & Claims HLLCA '73: Proceedings of a symposium on High-level-language computer architectureNovember 1973 Pages 109–116https://doi.org/10.1145/953144.953161Published:07 November 1973Publication History 1citation61DownloadsMetricsTotal Citations1Total Downloads61Last 12 Months11Last 6 weeks4 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteeReaderPDF

A Complete Mechanization of Second-Order Type Theory

A generalization of the resolution method for higher order logic is presented. The languages acceptable for the method are phrased in a theory of types of order w (all finite types)—including the λ-operator, propositional functors, and quantifiers. The resolution method is, of course, a machine-oriented theorem search procedure based on refutation. In order to make this method suitable for higher order logic, it was necessary to overcome two sorts of difficulties. The first is that the unifying substitution procedure—an essential feature of the classic first-order resolution—must be generalized (it is noted that for the higher order unification the proper notion of substitution will include λ-normalization). A general unification algorithm is produced and proved to be complete for second-order languages. The second difficulty arises because in higher order languages, semantic intent is essentially more “interwoven” in formulas than in first-order languages. Whereas quantifiers could be eliminated immediately in first-order resolution, their elimination must be deferred in the higher order case. The generalized resolution procedure which the author produces thus incorporates quantifier elimination along with the familiar features of unification and tautological reduction. It is established that the author's generalized resolution procedure is complete with respect to a natural notion of validity based on Henkin's general validity for type theory. Finally, there are presented examples of the application of the method to number theory and set theory.

A hierarchy of high order languages for systems programming

The programming of systems software in higher level languages has been a subject of much interest and debate. At Burroughs the debatability of the issue has long since ceased to exist since both the operating system and the compilers for the B5500 were successfully implemented in variants of ALGOL 60. The low manpower requirements and the ease of maintenance and modification have caused all concerned with the project to accept this approach without question. This technique has the added benefit of producing more reliable software due to the greatly reduced number of lines of code required. When the decision to produce a successor to the B5500 was made, there was no controversy over the use of high level languages but considerable debate over how high a level the languages should be. B5500 ESPOL (Executive System Problem Oriented Language), the operating system implementation language, contained many “unsafe” constructs, for example, the ability to directly address memory through a subscripted reference to an array known, strangely enough, as MEMORY. This allowed coding errors to produce undesirable side effects on the system. Examination of the algorithms used in most operating systems indicated that surprisingly few routines actually require such “unsafe” tools leading to the conclusion that the proper approach to the coding of the overall systems software might be a hierarchical set of systems programming languages with varying degrees of “safety.”