Durand, Irène, Strandh, Robert · Zenodo (CERN European Organization for Nuclear Research) · 2019
Some Common Lisp implementations evolve through careful modifications to an existing image. Most of the remaining implementations are bootstrapped using some lower-level language, typically C. As far as we know, only SBCL is bootstrapped from source code written mainly in Common Lisp. But in most cases, there is no profound reason for using a language other than Common Lisp for creating a Common Lisp system, though there are some annoying details that have to be dealt with. We describe the bootstrapping technique used with SICL, a modern implementation of Common Lisp. Though both SICL and the bootstrapping procedure for creating it are still being worked on, they are sufficiently evolved that the big picture outlined in this paper will remain valid. Our technique uses first-class global environments to isolate the host environment from the environments required during the bootstrapping procedure. Contrary to SBCL, and implementations written in some other language, in SICL, we build the CLOS MOP classes and generic functions first. This technique allows us to use the CLOS machinery for many other parts of the system, thereby decreasing the amount of special-purpose code, and improving maintainability of the system.
Cited by 0Open access
Irène Durand, Robert Strandh · HAL (Le Centre pour la Communication Scientifique Directe) · 2019
Some Common Lisp implementations evolve through careful modifications to an existing image. Most of the remaining implementations are bootstrapped using some lower-level language, typically C. As far as we know, only SBCL is bootstrapped from source code written mainly in Common Lisp. But in most cases, there is no profound reason for using a language other than Common Lisp for creating a Common Lisp system, though there are some annoying details that have to be dealt with. We describe the bootstrapping technique used with SICL, a modern implementation of Common Lisp. Though both SICL and the bootstrapping procedure for creating it are still being worked on, they are sufficiently evolved that the big picture outlined in this paper will remain valid. Our technique uses first-class global environments to isolate the host environment from the environments required during the bootstrapping procedure. Contrary to SBCL, and implementations written in some other language, in SICL, we build the CLOS MOP classes and generic functions first. This technique allows us to use the CLOS machinery for many other parts of the system, thereby decreasing the amount of special-purpose code, and improving maintainability of the system.
Cited by 0Open access
Börding, J. · Fraunhofer-Publica (Fraunhofer-Gesellschaft) · 1989
Cited by 0
Alan Bundy, Lincoln Wallen · 1984
Cited by 0
Kent M. Pitman · ACM SIGPLAN Lisp Pointers · 1992
"It sure is big." I have made the rounds proudly showing off my copy of the final document to my friends and colleagues, and this is invariably their first comment. Counting cover sheets, tables of contents, etc.---it's about 1350 pages. It is big---no doubt about that.
Cited by 0
Graham, Paul, 1964- · Bulletin of Miscellaneous Information (Royal Gardens Kew) · 1996
Cited by 0
Graham, P · CERN Document Server (European Organization for Nuclear Research) · 1995
Cited by 0
Mathematics and Computers in Simulation · 1989
Cited by 0
David S. Wile · 1993
Abstract : The principal goal of the COMMON LISP Framework project was to support Strategic Computing (SC) contractors with a comprehensive, state-of-the- art programming framework for the development and evolution of COMMON LISP programs. The CLF has affected the technical community by shaping both the structure of modern programming environments and the development paradigm they support. This structure rests upon an active objectbase which maintains integrity, integrated tools and provides persistence. CLF's integrity management is unique in providing declarative integrity condition statements--which can be reasoned about and analyzed--while still permitting efficient algorithmic maintenance of these conditions. Its declarative persistence mechanism, based on conceptual aggregations of objects, is also unique. Tools are integrated with the objectbase rather than each other. They gather their inputs from, and place their results back in, the objectbase and are invoked (demonically) by relative activity in the objectbase.
Cited by 0
Paul Graham · Medical Entomology and Zoology · 1993
1. The Extensible Language. 2. Functions. 3. Functional Programming. 4. Utility Functions. 5. Returning Functions. 6. Functions as Representation. 7. Macros. 8. When to Use Macros. 9. Variable Capture. 10. Other Macro Pitfalls. 11. Classic Macros. 12. Generalized Variables. 13. Computation at Compile-Time. 14. Anaphoric Macros. 15. Macros Returning Functions. 16. Macro-Defining Macros. 17. Read Macros. 18. Destructuring. 19. A Query Compiler. 20. Continuations. 21. Multiple Processes. 22. Nondeterminism. 23. Parsing with ATNs. 24. Prolog. 25. Object-Oriented Lisp. Appendix: Packages. Notes. Index.
Cited by 79
Rüdiger Esser, Elisabeth Feldmar · 1989
Im Verlauf der Entwicklung von LISP entstand eine Vielzahl unterschiedlicher Dialekte, die sich erheblich in der Menge der zur Verfügung gestellten Datentypen und Funktionen unterscheiden (vgl. Stoyan [1980]). So findet man zwar bei allen LISP-Dialekten die Datentypen Symbol, ganze Zahl und Liste sowie die Grundfunktionen CAR, CDR, CONS und COND; aber dann beginnen bald die Abweichungen. In einem Dialekt gibt es Funktionen, die man in einem anderen vergebens sucht, Funktionen mit gleicher Bedeutung haben verschiedene Namen, Funktionen mit gleichem Namen unterscheiden sich in der Bedeutung oder haben unterschiedliche Parameterlisten, Datentypen des einen Dialekts vermißt man in einem anderen etc. Darüber hinaus bieten die Dialekte unterschiedliche Funktionstypen mit unterschiedlichen Auswertungsregeln an. Die interpretierte Auswertung „normaler“ Funktionen erfolgt zwar einheitlich, bei kompilierten Funktionen stellt man jedoch Unterschiede fest.
Cited by 0
Scott D. Anderson, Adam Carlson, David L. Westbrook et al. · 1994
This document is the user manual for the Common Lisp Analytical Statistics Package (Clasp), a tool for visualizing and statistically analyzing data, and also for the Common Lisp Instrumentation Package (Clip), a tool for automating data collection and experimentation. Through statistics we attempt to separate those events which are simply due to chance from those which are related to other events in our world. Clasp provides the tools necessary for these tasks. Clasp and Clip are implemented in Common Lisp, with the Clasp user interface implemented in Clim, the Common Lisp Interface Manager. Along with describing the operation of Clasp and Clip, this manual details the Clasp programming interface, an aid for building extensions to Clasp. Contents 1 Introduction 1 1.1 History and Acknowledgments : : : : : : : : : : : : : : : : : : : : : : : : : 1 1.2 Design : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 2 1.3 Getting Clip/Clasp : : : : : : : : : : : :...
Cited by 0
Wendy L. Milner · 1987
Cited by 1
Franz. Berkeley, Calif. · CERN Document Server (European Organization for Nuclear Research) · 1988
Cited by 0
John Alan Mcdonald, John Alan Mcdonald, Michael Sannella · 1991
This document describes the Geometry module, a component of a system called Arizona, now under development at the U. of Washington. The Geometry module is intended to support common geometric calculations arising in graphics, numerical linear algebra, optimization, and scientific computing in general. The goal is to allow geometric computation using abstractions that directly represent high level mathematical concepts like affine spaces, vectors, and linear transformations, while retaining the level of performance provided by traditional scientific subroutine packages like Linpack[4]. It will be derived from Cactus [8, 6] and improved with ideas from work by DeRose [1, 2, 3] and Segal [14]. However, this release of the Geometry module does not support general geometric calculations. It consists of two submodules specialized for high performance in simple graphics calculations, Reeded by the SlateaJld Chltrt module$discnssed below. TheS?reenaeometrysublllodulesupp0l'tspa,lcullttions inadiscretetwo-.dilllenj>icmal coordinatesyst7mCalled Screen Space, ie. · abitmappeddisplay. The Chart Geometry submodnle supports calculations in a continuous (float) two-dimensional coordinate system, called Chart Space, a natural world space for simple scientific diltgrams. In addition, the Geometry module
Cited by 0
Masayuki Ida · 2024
Cited by 0
For Scienti Computing, N. Neuss · 2002
Lisp is a very exible and powerful language, but up to now it has not been used intensively for applications in scienti c computing.
Cited by 0
Ahmed Alneami, Paul Mc Kevitt · Artificial Intelligence Review · 1999
Cited by 0
MacLachlan, Rob · KiltHub Repository · 2018
Abstract: "CMU Common Lisp is an implementation of that Common Lisp is [sic] currently supported on MIPS-processor DECstations, Sparc-basedworkstations from Sun and the IBM RT PC, and other ports are planned. All architectures are supported under Mach, a Berkeley Unix 4.3 binary compatible operating system. The Sparc is also supported under SunOS. The largest single part of this document describes the Python compiler and the programming styles and techniques that the compiler encourages. The rest of the document describes extensions and the implementation dependent choices made in developing this implementation of Common Lisp.We have added several extensions, including a source level debugger, an interface to Unix system calls, a foreign function call interface, support for interprocess communication and remote procedure call, and other features that provide a good environment for developing Lisp code."
Cited by 0Open access
Practical Compiler For · 2007
Morph is a Common Lisp compiler for reversible inflectional morphology rules developed at the Center for Machine Translation at Carnegie Mellon University.
Cited by 0