LISP 1.5 Programmer's Manual

McCarthy, John; Abrahams, Paul; Edwards, Daniel; Hart, Timothy P.; Levin, Michael

doi:10.7551/mitpress/5619.001.0001

Cited by 138 publications

(117 citation statements)

References 0 publications

Supporting

Mentioning

112

Contrasting

Unclassified

Order By: Relevance

“…It has been more than three decades since exception-handling mechanisms [18][19][20] have been presented. During this time there have been a growing number of proposals for new ways to detect and handle exceptions.…”

Section: Related Workmentioning

confidence: 99%

A transactional model for automatic exception handling

Cabral

Marques

2011

Computer Languages, Systems & Structures

View full text Add to dashboard Cite

Exception handling mechanisms have been around for more than 30 years. Although modern exceptions systems are not very different from the early models, the large majority of modern programming languages rely on exception handling constructs for dealing with errors and abnormal situations. Exceptions have several advantages over other error handling mechanisms, such as the return of error codes or the usage of global state flags.Exceptions eliminate, for instance, the semipredicate problem, which occurs when a function fails to execute correctly but returns a valid value, thus leaving the caller unaware that an error occurred. Furthermore, exception mechanisms give the programmer an efficient error notification instrument, allow better recovery strategies based on the rich error data available on the exception objects, and allow the programmer to deal with abnormal situations in a civilized way. Nonetheless, and despite the mechanism's broadly recognized qualities on handling and recovering from errors, on our work we show that programmers are not using exception handling constructs as a recovery mean. Most times, when an error occurs, exceptions are silenced or just used to terminate a program in an orderly fashion, not really to recover. We show that the strategies for dealing with exceptions on non-critical programs are commonly non-existent or serve the final purpose of keeping track of problems for later analysis (debugging). Very little effort is normally spent trying to understand exceptions, their causes, and planning recovery actions. As a result, the amount of code found in these applications that is exclusively dedicated to exception handling is usually reduced. This is an unexpected fact. We would anticipate a much larger chunk of code dedicated to exception handling if we consider that: a) Simple operations, such as accessing a file on disk or sending a query to a database, can raise a large number of different exceptions; b) Each different exception type can have several distinct handling actions that may vary with location and time; c) Code for handling an exception can be as or more complex as the code raising the exception; d) In some programming languages (e.g., Java) it is mandatory to handle exceptions and declare their existence.The unwillingness of software designers to correctly deal with exceptions and follow some well known best-practices for exception handling contributes to the lowering of the quality of programs and their resilience to errors. The premise for our work is that something is not right with current exception handling models: they are not adequate enough for developers. The problem is even more worrisome if we consider that programming X ABSTRACT languages designers often neglect the exception mechanism and look at it more like an add-on for their language instead of a central part. As a consequence, software quality suffers as programmers feel that the task of writing good error handling code is too complex, unattractive and inefficient.In this dissertation we prop...

show abstract

Section: Related Workmentioning

confidence: 99%

A transactional model for automatic exception handling

Cabral

Marques

2011

Computer Languages, Systems & Structures

View full text Add to dashboard Cite

show abstract

“…Lisp [26] is a pure functional programming language based on one simple data structure: nested first-rest (car-cdr ) lists. Lisp has a fast interpretive full backtracking implementation that is widely used in artificial intelligence and well suited to rapid prototyping.…”

Section: The Turing Extender Languagementioning

confidence: 99%

TXL - A Language for Programming Language Tools and Applications

Cordy

2004

Electronic Notes in Theoretical Computer Science

View full text Add to dashboard Cite

TXL is a special-purpose programming language designed for creating, manipulating and rapidly prototyping language descriptions, tools and applications. TXL is designed to allow explicit programmer control over the interpretation, application, order and backtracking of both parsing and rewriting rules. Using first order functional programming at the higher level and term rewriting at the lower level, TXL provides for flexible programming of traversals, strategies, guards, scope of application and parameterized context. This flexibility has allowed TXL users to express and experiment with both new ideas in parsing, such as robust, island and agile parsing, and new paradigms in rewriting, such as XML markup, rewriting strategies and contextualized rules, without any change to TXL itself. In this paper I outline the history, evolution and concepts of TXL with emphasis on what makes it different from other language manipulation tools, and give examples of its use in expressing and applying recent new paradigms in language processing.

show abstract

“…Combined continuous/discrete (Pritsker, 1974) LISP Symbol manipulation, reflection (McCarthy, 1962) AUTOBIOGRAPHICAL RETROSPECTIVES 225 In this way, DEVS, Discrete Event Systems Specification, came about as filling the missing gap in mathematical systems theory, much as new elements are anticipated by Mendeleev's periodic table of elements. For this to happen, someone would have to have been familiar with state of event-oriented simulation languages and understood the essence of the mathematical systems theory of the time.…”

Section: Simulation Languagesmentioning

confidence: 99%

Systems Movement: Autobiographical Retrospectives

2003

International Journal of General Systems

View full text Add to dashboard Cite

Systems Movement: Autobiographical Retrospectives is a special section of this Journal, the purpose of which is to produce, via invited autobiographical articles, historical information and insights regarding the thought processes and individual motivations of leading figures in the systems movement. This valuable information is normally not included in regular publications that tend to focus on results rather than the creative process leading to those results. The autobiographical articles are likely to help us to improve our understanding of how, and why, the systems movement has progressed since its emergence in the mid-20th century. Each article in this section is published strictly by invitation extended to individual authors by the Editor, and is based on the recognition that these individuals have made major contributions to systems movement.

show abstract

LISP 1.5 Programmer's Manual

Abstract: The Research Laboratory af Electronics is an interdepartmental laboratory in which faculty members and graduate students from numerous academic departments conduct research.

Cited by 138 publications

References 0 publications

A transactional model for automatic exception handling

A transactional model for automatic exception handling

TXL - A Language for Programming Language Tools and Applications

Systems Movement: Autobiographical Retrospectives

Contact Info

Product

Resources

About