The problem of programming a computer fo determine whether or not a string of characters is a misspelling of a given word wos considered. A number of algorithms were evaluated--some proposed by other writers, some by the author. These techniques were tested on a collection of misspellings made by students at various grade levels.While many of the methods were clearly unsatisfactory, some gave as few as 2.1 percent incorrect determinations.
In this paper we describe how we have combined a number of tools (most of which understand a particular programming tanguage) into a single system to aid in the reading, writing, and running of programs. We discuss the efficacy and the structure of our system. For the last two years the system has been used to build itself; it currently consists of 500 kilobytes of machine code (25 ,000 lines of LISP/370 code j and approximately one hundred commands with large numbers of options. We will describe some of the experience we have gained in evolving this system, We first indicate the system components which users have found most important; some of the tools described here are new in the literature. Second, we emphasize how these tools form a synergistic union, and we illustrate this point with a number of examples. Thkd, we illustrate the use of various system commands in the development of a simple program. Fourth, we discuss the implementation of the system components and indicate how some of them have been generalized.
No abstract
in 1974, a group at IBM Research began work on a new implementation of Lisp. Because the work was initially done for internal use only, many design decisions led the developers away from the more traditional Lisp paths. The most important design decision was to create a language which would have consistent semantics between compilation and interpretation. This paper takes a retrospective look at the decisions we made to see how they have stood up against the test of time and usage, especially when seen against the decisions made for Common Lisp.The Lisp language issues discussed include scoping, operator evaluation and consistency, and state saving. Compiler issues include the integration of assembly code into Lisp programs, our underlying formal semantics, and optimization. Our programming environment is as sophisticated as the majority of Lisp systems. Aiming at hardware such as the IBM 3270 terminals has affected the design of the tools that make up this environment. These issues will also be discussed.
The two most common dynamic binding models used in Lisp systems are shallow and deep binding. For a succinct summery of these see Padget and Fitch [1985], which includes a proposed third model. It is often claimed that shallow binding are unsuited to systems which allow context switching. We wish to describe an alternative binding model, deep binding with cacheing, which provides the efficiency of shallow binding in "ordinary" call/return control, while exhibiting the ease of context switching of deep binding. This binding model was implemented in the Lisp system built at the IBM Research Center, later elaborated into LISP/VM. In this article the term LISP/VM will be used to encompass both that program and all of its progenitors developed at IBM Research.
scite is a Brooklyn-based organization that helps researchers better discover and understand research articles through Smart Citations–citations that display the context of the citation and describe whether the article provides supporting or contrasting evidence. scite is used by students and researchers from around the world and is funded in part by the National Science Foundation and the National Institute on Drug Abuse of the National Institutes of Health.
customersupport@researchsolutions.com
10624 S. Eastern Ave., Ste. A-614
Henderson, NV 89052, USA
Copyright © 2024 scite LLC. All rights reserved.
Made with 💙 for researchers
Part of the Research Solutions Family.