Showing papers in "ACM Sigplan Lisp Pointers in 1991"
TL;DR: The report gives a defining description of the programming language Scheme, a statically scoped and properly tail-recursive dialect of the Lisp programming language invented by Guy Lewis Steele Jr. and Gerald Jay Sussman.
Abstract: The report gives a defining description of the programming language Scheme. Scheme is a statically scoped and properly tail-recursive dialect of the Lisp programming language invented by Guy Lewis Steele Jr. and Gerald Jay Sussman. It was designed to have an exceptionally clear and simple semantics and few different ways to form expressions. A wide variety of programming paradigms, including imperative, functional, and message passing styles, find convenient expression in Scheme.
522 citations
TL;DR: The facility described here is based on explicit renaming of identifiers, and was developed for the first implementation of the hygienic macro expansion algorithm described in [2], and remains one of the easiest to understand.
Abstract: This paper describes an alternative to the low-level macro facility described in the Revised4 Report on the Algorithmic Language Scheme [1]. The facility described here is based on explicit renaming of identifiers, and was developed for the first implementation of the hygienic macro expansion algorithm described in [2]. It was the first low-level macro facility to be designed for compatibility with a high-level hygienic macro system, and it remains one of the easiest to understand.
23 citations
[...]
TL;DR: This issue contains three more articles on the subject of macros in Scheme, counting the article you are reading, and I wrote this as an introduction to the other two articles, because it is very hard to understand their purpose without some background onmacros in Scheme.
Abstract: Although macros are even older than Lisp, Scheme has just become the first block-structured programming language to support a reliable macro system. This macro system is described in the appendix to the Revised4Report on the Algorithmic Language Scheme, which appeared in the previous issue of Lisp Pointers. This issue contains three more articles on the subject of macros in Scheme, counting the article you are reading. I wrote this as an introduction to the other two articles, because it is very hard to understand their purpose without some background on macros in Scheme.
20 citations
TL;DR: This document describes syntactic closures, a low-level macro facility for the Scheme programming language that is an alternative to the low- level macro facility described in the Revised 4 Report on Scheme.
Abstract: This document describes syntactic closures, a low-level macro facility for the Scheme programming language. The facility is an alternative to the low-level macro facility described in the Revised 4 Report on Scheme. This document is an addendum to that report.
13 citations
TL;DR: META is reviewed, a classic technique for building recursive descent parsers, that is both simple and efficient, and the execution time of this parsing method is compared to the built-in methods of Common Lisp.
Abstract: We review META, a classic technique for building recursive descent parsers, that is both simple and efficient While META does not handle all possible regular or context-free grammars, it handles a surprisingly large fraction of the grammars encountered by Lisp programmers We show how META can be used to parse streams, strings and lists---including Common Lisp's hairy lambda expression parameter lists Finally, we compare the execution time of this parsing method to the built-in methods of Common Lisp
8 citations
TL;DR: This paper describes a set of Lisp macros that enable the use of "list comprehensions" which are a very powerful notation that provides a very compact expression of common list operations.
Abstract: This paper describes a set of Lisp macros that enable the use of "list comprehensions" which are a very powerful notation that provides a very compact expression of common list operations see [2] for a full discussion. List comprehensions have been introduced by David Turner in KRC, where they were called ZF-expressions [7]. They have since been introduced in several other pure functional languages like SASL [8], Miranda1 [5] and Haskell [3].
5 citations
TL;DR: The KT regression tester presented here supports the regression testing of systems wri t ten in Common Lisp and is an interesting example of the power of Lisp.
Abstract: How often have you made a change in a system to fix a bug or add a feature and been totally sure that the change did not affect anything else, only to discover weeks or months later tha t the change broke something? In my personal experience, the single most valuable software maintenance tool is a regression tester, which maintains a suite of tests for a system and can run them automatical ly when the system is changed. The term \"regression testing\" is used, because each version of the system being tested is compared with the previous version to make sure that the new version has not regressed by losing any of the tested capabilities. The more comprehensive the test suite is, the more valuable this comparison becomes. Creating a comprehensive test suite for a system requires significant effort, and running a test suite can require significant amounts of computer time. However, given a comprehensive test suite, regression testing detects an impressive number of bugs with remarkably little human effort. The KT regression tester presented here supports the regression testing of systems wri t ten in Common Lisp. In addition to being a valuable tool, RT is an interesting example of the power of Lisp. The unified nature of the Lisp programming environment and the fact that Lisp programs can be manipulated as da ta allows RT to be implemented in two pages of code. Merely implement ing a batch-mode regression tester using an Algol-like language in a typical programming environment would require much more code. Implement ing a highly interactive system like RT would be a major undertaking. U s e r ' s M a n u a l for RT
4 citations
TL;DR: A software module that allows a Common Lisp program to access a relational database management system through a foreign function interface and structure accessor functions is discussed.
Abstract: Access to persistent database storage from Common Lisp applications is an increasingly frequent requirement. This paper discusses a software module that allows a Common Lisp program to access a relational database management system. Database queries are expressed as SQL statements. In Common Lisp, the SQL query is represented as a string, which allows sequence functions to be used to construct the query. Through a foreign function interface, the SQL query is passed from Lisp to a C component. The C component contains embedded database statements to utilize the dynamic SQL facility provided by the database management system. The database result table is returned to Lisp. Functions are provided to convert the returned data into a list of structures. Each structure corresponds to one row in the database result table. Structure accessor functions allow each individual attribute (field) in the structure representation of a row in the result table to be obtained.
4 citations
TL;DR: Benefits and experiences in real industrial use of DMG are presented; and practical issues on using a CLOS-based graphical user interface library are discussed.
Abstract: DMG is a development environment for building diagnostics applications of electrical equipment. Knowledge contained in an equipment model is compiled into a decision-tree like diagnostic logic, which is then used visually to pinpoint deficiencies in the performance of the equipment. The delivery application is a hypertext document which combines the diagnostic logic with links to sources of additional information. Benefits and experiences in real industrial use of DMG are presented; and practical issues on using a CLOS-based graphical user interface library are discussed.
2 citations
TL;DR: The value of a suite of test cases depends critically on its coverage, and something should be done to assess the coverage of a test suites, because a test suite with poor coverage has little value.
Abstract: The value of a suite of test cases depends critically on its coverage. Ideally a suite should test every facet of the specification for a program and every facet of the algorithms used to implement the specification. Unfortunately, there is no practical way to be sure that complete coverage has been achieved. However, something should be done to assess the coverage of a test suite, because a test suite with poor coverage has little value.
1 citations