DOCSLIB.ORG

Allegro CL User Guide

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Allegro CL User Guide Allegro CL User Guide Volume 1 (of 2) version 4.3 March, 1996 Copyright and other notices: This is revision 6 of this manual. This manual has Franz Inc. document number D-U-00-000-01-60320-1-6. Copyright 1985-1996 by Franz Inc. All rights reserved. No part of this pub- lication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means electronic, mechanical, by photocopying or recording, or otherwise, without the prior and explicit written permission of Franz incorpo- rated. Restricted rights legend: Use, duplication, and disclosure by the United States Government are subject to Restricted Rights for Commercial Software devel- oped at private expense as specified in DOD FAR 52.227-7013 (c) (1) (ii). Allegro CL and Allegro Composer are registered trademarks of Franz Inc. Allegro Common Windows, Allegro Presto, Allegro Runtime, and Allegro Matrix are trademarks of Franz inc. Unix is a trademark of AT&T. The Allegro CL software as provided may contain material copyright Xerox Corp. and the Open Systems Foundation. All such material is used and distrib- uted with permission. Other, uncopyrighted material originally developed at MIT and at CMU is also included. Appendix B is a reproduction of chapters 5 and 6 of The Art of the Metaobject Protocol by G. Kiczales, J. des Rivieres, and D. Bobrow. All this material is used with permission and we thank the authors and their publishers for letting us reproduce their material. Contents Volume 1 Preface 1 Introduction 1.1 The language 1-1 1.2 History 1-1 1.3 Format of the manual 1-2 1.4 An outline of the manual 1-3 1.5 Assistance available on the internet and the World Wide Web 1-4 The Allegro CL FAQ 1-4 Patches 1-4 Should you get all patches? 1-4 1.6 Comments and suggestions 1-5 1.7 Reporting bugs 1-5 Where to report bugs and send questions 1-6 1.8 Patches 1-6 Further information 1-6 Old ftp site no longer contains patches 1-6 2 Customizing and executing Common Lisp 2.1 How to run Lisp 2-2 2.1.1 How to run Lisp: general information 2-2 The image name 2-2 Image you execute may be a shell script 2-2 Command line arguments 2-3 Files Lisp must find to start up and files it may need later 2-4 Files Lisp needs to start up 1: .so files built with image 2-4 Files Lisp needs to start up 2: the Lisp home 2-5 What to do when Lisp cannot find the Lisp home 2-5 How does Lisp find loaded .so files? 2-7 The start-up message 2-8 2.1.2 Running Lisp as a subprocess of Emacs 2-9 Starting Lisp as a subprocess of Emacs the first time 2-9 Starting Lisp within Emacs after the first time 2-10 What if the Emacs-Lisp interface does not start? 2-10 2.1.3 Starting Lisp from a shell 2-11 2.1.4 Start-up problems 2-11 Lisp won’t start up at all (killed immediately) 2-11 2.2 How to exit Lisp 2-12 How to exit for sure 2-12 2.3 What Lisp does when as it starts up 2-13 ALLEGRO COMMON LISP 4.3 c - 1 2.4 Initialization and the sys:siteinit.cl and .clinit.cl files 2-14 Errors in an initialization file 2-14 No top-level commands in initialization files 2-15 Cannot (effectively) set a variable bound by load 2-15 Starting Allegro Composer from .clinit.cl 2-15 2.4.1 Setting global variables in initialization files 2-16 Where are the bindings defined? 2-16 Many binding are to specific values, not to the variables actual value 2-16 How to set the value so a listener sees it? 2-17 Definitions and examples. 2-17 2.4.2 A sample initialization file 2-18 2.5 After Lisp starts up 2-19 The initial prompt 2-19 Errors 2-20 What if the system seems to hang? 2-20 Enough C-c’s will always interrupt 2-20 Help while running Lisp 2-21 2.6 Files that may be looked for on startup and after startup 2-22 Table 2 notes: 2-23 2.7 Reader case modes 2-24 2.7.1 Changing case modes 2-26 2.7.2 More on compatibility and case preference 2-27 3 Implementation and extensions 3.1 Allegro CL and the ANSI CL standard 3-2 Compatibility with pre-ANSI CLtL-1 in Allegro CL 4.3 3-2 Other package changes and compile-time-too behavior 3-3 The function data type 3-4 3.1.1 CLOS and MOP 3-4 CLOS and MOP conformance 3-5 CLOS optimization 3-6 3.2 Data types 3-7 3.2.1 Characters 3-7 3.3 Pathnames 3-8 Unix symbolic links and truenames 3-8 3.3.1 Parsing Unix pathnames 3-9 Preprocessing 3-9 Determining the :directory component 3-9 Determining the :name component 3-10 Determining the :type component 3-10 Anomalies 3-10 Table of examples 3-11 3.3.2 The directory component of merged Unix pathnames 3-12 3.3.3 Logical pathnames 3-12 Logical pathnames: introduction 3-12 Logical pathnames: implementation details 3-13 Logical pathnames: implementation details 3-14 3.4 Packages and package locking 3-17 Packages in Allegro CL 3-17 Notes on specific packages 3-17 Package nicknames 3-18 c - 2 ALLEGRO COMMON LISP 4.3 Package locking and package definition locking 3-20 Package locking: 3-20 Package definition locking: 3-21 Implementation packages 3-22 Package locked errors 3-23 Locally circumventing package locked errors 3-24 The packages locked by default 3-24 Justification for package locking 3-25 3.5 Extensions 3-25 3.5.1 List of extensions 3-26 3.6 Autoloading 3-26 Where the autoloaded files are located 3-27 Common Lisp symbols 3-27 Major extensions 3-27 How to load modules 3-27 3.7 Miscellaneous extensions and implementation details 3-28 3.7.1 Extensions to Common Lisp functions 3-31 The random function 3-35 Extensions to make-hash-table 3-35 3.8 Errors 3-36 3.8.1 Some common errors 3-37 3.9 A note on portability 3-38 4 The top-level 4.1 Initialization 4-1 4.2 Interaction and the prompt 4-2 4.3 Commands and expressions 4-4 4.3.1 Case sensitivity of input 4-4 4.3.2 Getting help 4-5 4.3.3 Command and expression history 4-5 Anomalies with the :history list 4-7 4.3.4 Break levels 4-8 4.3.5 Commands for compiling and loading 4-11 File arguments are read as strings 4-11 4.3.6 Top-level interaction with multiprocessing 4-12 4.3.7 Commands for killing processes and exiting Lisp 4-14 4.3.8 Miscellaneous commands 4-15 4.4 Top-level variables 4-16 4.5 Adding new top-level commands 4-18 5 The debugger Getting out of the debugger 5-1 5.1 Internal functions 5-2 5.2 Debugging background processes 5-2 5.3 Stack commands 5-3 5.3.1 zoom 5-4 :brief, :moderate, and :verbose 5-7 :all t and :all nil 5-8 :function t and :function nil 5-8 :specials t and :specials nil 5-9 ALLEGRO COMMON LISP 4.3 c - 3 :relative t and :relative nil 5-9 The :bt command for a quick look at the stack 5-9 5.3.1.1 Variables that affect the behavior of :zoom 5-10 5.3.1.2 Special handling of certain errors 5-11 5.3.2 :zoom analogs and stack movement commands 5-12 5.3.3 Commands that hide frames 5-13 5.3.4 Frame information commands 5-15 5.3.5 Local variables and evaluation 5-16 Local variables and the debugger 5-17 Discard local variable information before dumplisp 5-17 Summary of this discussion 5-17 What are local variables? 5-18 How does the compiler treat local variables? 5-18 What is the difference between using registers and using the stack? 5-19 Live and dead ranges of local variables 5-19 Locals and functions in the tail position 5-19 Example showing live range 5-19 The debug=1 behavior with locals 5-21 The behavior with debug=2 5-21 Problem with debug=1 and debug=2 behavior before a local has a value 5-22 Why only have good behavior of locals at debug=3? 5-23 The behavior with debug=3 (and speed < 3) 5-23 The behavior with debug=3 and speed=3 5-24 I compiled with debug=3 but I want to see dead locals anyway 5-26 5.3.6 Break on exit 5-27 5.3.7 :return and :restart 5-28 5.3.8 Ghost frames in backtraces 5-33 Summary of this section 5-33 What is a ghost frame? 5-35 What kinds of optimizations cause ghost frames? 5-35 How does the debugger know about ghost frames? 5-36 When will the debugger display ghost frames? 5-36 Can I return from or restart a ghost frame? 5-37 What do the suspension points (‘...’) mean in a ghost frame? 5-37 The ghost frame has no ‘...’s; are all possible frames displayed? 5-37 No ghost frames are displayed.
Load more

Recommended publications
  • Introduction to Programming in Lisp
    Introduction to Programming in Lisp Supplementary handout for 4th Year AI lectures · D W Murray · Hilary 1991 1 Background There are two widely used languages for AI, viz. Lisp and Prolog. The latter is the language for Logic Programming, but much of the remainder of the work is programmed in Lisp. Lisp is the general language for AI because it allows us to manipulate symbols and ideas in a commonsense manner. Lisp is an acronym for List Processing, a reference to the basic syntax of the language and aim of the language. The earliest list processing language was in fact IPL developed in the mid 1950’s by Simon, Newell and Shaw. Lisp itself was conceived by John McCarthy and students in the late 1950’s for use in the newly-named field of artificial intelligence. It caught on quickly in MIT’s AI Project, was implemented on the IBM 704 and by 1962 to spread through other AI groups. AI is still the largest application area for the language, but the removal of many of the flaws of early versions of the language have resulted in its gaining somewhat wider acceptance. One snag with Lisp is that although it started out as a very pure language based on mathematic logic, practical pressures mean that it has grown. There were many dialects which threaten the unity of the language, but recently there was a concerted effort to develop a more standard Lisp, viz. Common Lisp. Other Lisps you may hear of are FranzLisp, MacLisp, InterLisp, Cambridge Lisp, Le Lisp, ... Some good things about Lisp are: • Lisp is an early example of an interpreted language (though it can be compiled).
    [Show full text]
  • High-Level Language Features Not Found in Ordinary LISP. the GLISP
    DOCUMENT RESUME ED 232 860 SE 042 634 AUTHOR Novak, Gordon S., Jr. TITLE GLISP User's Manual. Revised. INSTITUTION Stanford Univ., Calif. Dept. of Computer Science. SPONS AGENCY Advanced Research Projects Agency (DOD), Washington, D.C.; National Science Foundation, Washington, D.C. PUB DATE 23 Nov 82 CONTRACT MDA-903-80-c-007 GRANT SED-7912803 NOTE 43p.; For related documents, see SE 042 630-635. PUB TYPE Guides General (050) Reference Materials General (130) EDRS PRICE MF01/PCO2 Plus Postage. DESCRIPTORS *Computer Programs; *Computer Science; Guides; *Programing; *Programing Languages; *Resource Materials IDENTIFIERS *GLISP Programing Language; National Science Foundation ABSTRACT GLISP is a LISP-based language which provides high-level language features not found in ordinary LISP. The GLISP language is implemented by means of a compiler which accepts GLISP as input and produces ordinary LISP as output. This output can be further compiled to machine code by the LISP compiler. GLISP is available for several ISP dialects, including Interlisp, Maclisp, UCI Lisp, ELISP, Franz Lisp, and Portable Standard Lisp. The goal of GLISP is to allow structured objects to be referenced in a convenient, succinct language and to allow the structures of objects to be changed without changing the code which references the objects. GLISP provides both PASCAL-like and English-like syntaxes; much of the power and brevity of GLISP derive from the compiler features necessary to support the relatively informal, English-like language constructs. Provided in this manual is the documentation necessary for using GLISP. The documentation is presented in the following sections: introduction; object descriptions; reference to objects; GLISP program syntax; messages; context rules and reference; GLISP and knowledge representation languages; obtaining and using GLISP; GLISP hacks (some ways of doing things in GLISP which might not be entirely obvious at first glance); and examples of GLISP object declarations and programs.
    [Show full text]
  • View of XML Technology
    AN APPLICATION OF EXTENSlBLE MARKUP LANGUAGE FOR INTEGRATION OF KNOWLEDGE-BASED SYSTEM WITH JAVA APPLICATIONS A Thesis Presented to The Faculty of the Fritz J. and Dolores H. Russ College of Engineering and Technology Ohio University In Partial Fulfillment of the Requirement for the Degree Master of Science BY Sachin Jain November, 2002 ACKNOWLEDGEMENTS It is a pleasure to thank the many people who made this thesis possible. My sincere gratitude to my thesis advisor, Dr. DuSan Sormaz, who helped and guided me towards implementing the ideas presented in this thesis. His dedication to research and his effort in the development of my thesis was an inspiration throughout this work. The thesis would not be successful without other members of my committee, Dr. David Koonce and Dr. Constantinos Vassiliadis. Special thanks to them for their substantial help and suggestions during the development of this thesis. I would like also to thank Dr. Dale Masel for his class on guidelines for how to write thesis. Thanlts to my fellow colleagues and members of the lMPlanner Group, Sridharan Thiruppalli, Jaikumar Arumugam and Prashant Borse for their excellent cooperation and suggestions. A lot of infom~ation~1sef~11 to the work was found via the World Wide Web; 1 thank those who made their material available on the Web and those who kindly responded back to my questions over the news-groups. Finally, it has been pleasure to pursue graduate studies at IMSE department at Ohio University, an unique place that has provided me with great exposures to intricacies underlying development, prograrn~ningand integration of different industrial systems; thus making this thesis posslbie.
    [Show full text]
  • The Copyright Law of the United States (Title 17, U.S
    NOTICE WARNING CONCERNING COPYRIGHT RESTRICTIONS: The copyright law of the United States (title 17, U.S. Code) governs the making of photocopies or other reproductions of copyrighted material. Any copying of this document without permission of its author may be prohibited by law. CMU Common Lisp User's Manual Mach/IBM RT PC Edition David B. McDonald, Editor April 1989 CMU-CS-89-132 . School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 This is a revised version of Technical Report CMU-CS-87-156. Companion to Common Lisp: The Language Abstract CMU Common Lisp is an implementation of Common Lisp that currently runs on the IBM RT PC under Mach, a Berkeley Unix 4.3 binary compatible operating system. This document describes the implementation dependent choices made in developing this implementation of Common Lisp. Also, several extensions have been added, including the proposed error system, a stack crawling debugger, a stepper, an interface to Mach system calls, a foreign function call interface, the ability to write assembler language routines, and other features that provide a good environment for developing Lisp code. This research was sponsored by the Defense Advanced Research Projects Agency (DOD), ARPA Order No. 4976 under contract F33615-87-C-1499 and monitored by the Avionics Laboratory, Air Force Wright Aeronautical Laboratories, Aeronautical Systems Division (AFSC), Wright-Patterson AFB, OHIO 45433-6543. The views and conclusions contained in this document are those of the authors and should not be interpreted as representing the official policies, either expressed or implied, of the Defense Advanced Research Projects Agency or the U.S.
    [Show full text]
  • The Machine That Builds Itself: How the Strengths of Lisp Family
    Khomtchouk et al. OPINION NOTE The Machine that Builds Itself: How the Strengths of Lisp Family Languages Facilitate Building Complex and Flexible Bioinformatic Models Bohdan B. Khomtchouk1*, Edmund Weitz2 and Claes Wahlestedt1 *Correspondence: [email protected] Abstract 1Center for Therapeutic Innovation and Department of We address the need for expanding the presence of the Lisp family of Psychiatry and Behavioral programming languages in bioinformatics and computational biology research. Sciences, University of Miami Languages of this family, like Common Lisp, Scheme, or Clojure, facilitate the Miller School of Medicine, 1120 NW 14th ST, Miami, FL, USA creation of powerful and flexible software models that are required for complex 33136 and rapidly evolving domains like biology. We will point out several important key Full list of author information is features that distinguish languages of the Lisp family from other programming available at the end of the article languages and we will explain how these features can aid researchers in becoming more productive and creating better code. We will also show how these features make these languages ideal tools for artificial intelligence and machine learning applications. We will specifically stress the advantages of domain-specific languages (DSL): languages which are specialized to a particular area and thus not only facilitate easier research problem formulation, but also aid in the establishment of standards and best programming practices as applied to the specific research field at hand. DSLs are particularly easy to build in Common Lisp, the most comprehensive Lisp dialect, which is commonly referred to as the “programmable programming language.” We are convinced that Lisp grants programmers unprecedented power to build increasingly sophisticated artificial intelligence systems that may ultimately transform machine learning and AI research in bioinformatics and computational biology.
    [Show full text]
  • Bringing GNU Emacs to Native Code
    Bringing GNU Emacs to Native Code Andrea Corallo Luca Nassi Nicola Manca [email protected] [email protected] [email protected] CNR-SPIN Genoa, Italy ABSTRACT such a long-standing project. Although this makes it didactic, some Emacs Lisp (Elisp) is the Lisp dialect used by the Emacs text editor limitations prevent the current implementation of Emacs Lisp to family. GNU Emacs can currently execute Elisp code either inter- be appealing for broader use. In this context, performance issues preted or byte-interpreted after it has been compiled to byte-code. represent the main bottleneck, which can be broken down in three In this work we discuss the implementation of an optimizing com- main sub-problems: piler approach for Elisp targeting native code. The native compiler • lack of true multi-threading support, employs the byte-compiler’s internal representation as input and • garbage collection speed, exploits libgccjit to achieve code generation using the GNU Com- • code execution speed. piler Collection (GCC) infrastructure. Generated executables are From now on we will focus on the last of these issues, which con- stored as binary files and can be loaded and unloaded dynamically. stitutes the topic of this work. Most of the functionality of the compiler is written in Elisp itself, The current implementation traditionally approaches the prob- including several optimization passes, paired with a C back-end lem of code execution speed in two ways: to interface with the GNU Emacs core and libgccjit. Though still a work in progress, our implementation is able to bootstrap a func- • Implementing a large number of performance-sensitive prim- tional Emacs and compile all lexically scoped Elisp files, including itive functions (also known as subr) in C.
    [Show full text]
  • Common Lispworks User Guide
    LispWorks® for the Windows® Operating System Common LispWorks User Guide Version 5.1 Copyright and Trademarks Common LispWorks User Guide (Windows version) Version 5.1 February 2008 Copyright © 2008 by LispWorks Ltd. All Rights Reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of LispWorks Ltd. The information in this publication is provided for information only, is subject to change without notice, and should not be construed as a commitment by LispWorks Ltd. LispWorks Ltd assumes no responsibility or liability for any errors or inaccuracies that may appear in this publication. The software described in this book is furnished under license and may only be used or copied in accordance with the terms of that license. LispWorks and KnowledgeWorks are registered trademarks of LispWorks Ltd. Adobe and PostScript are registered trademarks of Adobe Systems Incorporated. Other brand or product names are the registered trade- marks or trademarks of their respective holders. The code for walker.lisp and compute-combination-points is excerpted with permission from PCL, Copyright © 1985, 1986, 1987, 1988 Xerox Corporation. The XP Pretty Printer bears the following copyright notice, which applies to the parts of LispWorks derived therefrom: Copyright © 1989 by the Massachusetts Institute of Technology, Cambridge, Massachusetts. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, pro- vided that this copyright and permission notice appear in all copies and supporting documentation, and that the name of M.I.T.
    [Show full text]
  • The Uses of Animation 1
    The Uses of Animation 1 1 The Uses of Animation ANIMATION Animation is the process of making the illusion of motion and change by means of the rapid display of a sequence of static images that minimally differ from each other. The illusion—as in motion pictures in general—is thought to rely on the phi phenomenon. Animators are artists who specialize in the creation of animation. Animation can be recorded with either analogue media, a flip book, motion picture film, video tape,digital media, including formats with animated GIF, Flash animation and digital video. To display animation, a digital camera, computer, or projector are used along with new technologies that are produced. Animation creation methods include the traditional animation creation method and those involving stop motion animation of two and three-dimensional objects, paper cutouts, puppets and clay figures. Images are displayed in a rapid succession, usually 24, 25, 30, or 60 frames per second. THE MOST COMMON USES OF ANIMATION Cartoons The most common use of animation, and perhaps the origin of it, is cartoons. Cartoons appear all the time on television and the cinema and can be used for entertainment, advertising, 2 Aspects of Animation: Steps to Learn Animated Cartoons presentations and many more applications that are only limited by the imagination of the designer. The most important factor about making cartoons on a computer is reusability and flexibility. The system that will actually do the animation needs to be such that all the actions that are going to be performed can be repeated easily, without much fuss from the side of the animator.
    [Show full text]
  • Omnipresent and Low-Overhead Application Debugging
    Omnipresent and low-overhead application debugging Robert Strandh [email protected] LaBRI, University of Bordeaux Talence, France ABSTRACT application programmers as opposed to system programmers. The state of the art in application debugging in free Common The difference, in the context of this paper, is that the tech- Lisp implementations leaves much to be desired. In many niques that we suggest are not adapted to debugging the cases, only a backtrace inspector is provided, allowing the system itself, such as the compiler. Instead, throughout this application programmer to examine the control stack when paper, we assume that, as far as the application programmer an unhandled error is signaled. Most such implementations do is concerned, the semantics of the code generated by the not allow the programmer to set breakpoints (unconditional compiler corresponds to that of the source code. or conditional), nor to step the program after it has stopped. In this paper, we are mainly concerned with Common Furthermore, even debugging tools such as tracing or man- Lisp [1] implementations distributed as so-called FLOSS, i.e., ually calling break are typically very limited in that they do \Free, Libre, and Open Source Software". While some such not allow the programmer to trace or break in important sys- implementations are excellent in terms of the quality of the tem functions such as make-instance or shared-initialize, code that the compiler generates, most leave much to be simply because these tools impact all callers, including those desired when it comes to debugging tools available to the of the system itself, such as the compiler.
    [Show full text]
  • How Lisp Systems Look Different in Proceedings of European Conference on Software Maintenance and Reengineering (CSMR 2008)
    How Lisp Systems Look Different In Proceedings of European Conference on Software Maintenance and Reengineering (CSMR 2008) Adrian Dozsa Tudor Gˆırba Radu Marinescu Politehnica University of Timis¸oara University of Berne Politehnica University of Timis¸oara Romania Switzerland Romania [email protected] [email protected] [email protected] Abstract rently used in a variety of domains, like bio-informatics (BioBike), data mining (PEPITe), knowledge-based en- Many reverse engineering approaches have been devel- gineering (Cycorp or Genworks), video games (Naughty oped to analyze software systems written in different lan- Dog), flight scheduling (ITA Software), natural language guages like C/C++ or Java. These approaches typically processing (SRI International), CAD (ICAD or OneSpace), rely on a meta-model, that is either specific for the language financial applications (American Express), web program- at hand or language independent (e.g. UML). However, one ming (Yahoo! Store or reddit.com), telecom (AT&T, British language that was hardly addressed is Lisp. While at first Telecom Labs or France Telecom R&D), electronic design sight it can be accommodated by current language inde- automation (AMD or American Microsystems) or planning pendent meta-models, Lisp has some unique features (e.g. systems (NASA’s Mars Pathfinder spacecraft mission) [16]. macros, CLOS entities) that are crucial for reverse engi- neering Lisp systems. In this paper we propose a suite of Why Lisp is Different. In spite of its almost fifty-year new visualizations that reveal the special traits of the Lisp history, and of the fact that other programming languages language and thus help in understanding complex Lisp sys- borrowed concepts from it, Lisp still presents some unique tems.
    [Show full text]
  • An Evaluation of Go and Clojure
    An evaluation of Go and Clojure A thesis submitted in partial satisfaction of the requirements for the degree Bachelors of Science in Computer Science Fall 2010 Robert Stimpfling Department of Computer Science University of Colorado, Boulder Advisor: Kenneth M. Anderson, PhD Department of Computer Science University of Colorado, Boulder 1. Introduction Concurrent programming languages are not new, but they have been getting a lot of attention more recently due to their potential with multiple processors. Processors have gone from growing exponentially in terms of speed, to growing in terms of quantity. This means processes that are completely serial in execution will soon be seeing a plateau in performance gains since they can only rely on one processor. A popular approach to using these extra processors is to make programs multi-threaded. The threads can execute in parallel and use shared memory to speed up execution times. These multithreaded processes can significantly speed up performance, as long as the number of dependencies remains low. Amdahl‘s law states that these performance gains can only be relative to the amount of processing that can be parallelized [1]. However, the performance gains are significant enough to be looked into. These gains not only come from the processing being divvied up into sections that run in parallel, but from the inherent gains from sharing memory and data structures. Passing new threads a copy of a data structure can be demanding on the processor because it requires the processor to delve into memory and make an exact copy in a new location in memory. Indeed some studies have shown that the problem with optimizing concurrent threads is not in utilizing the processors optimally, but in the need for technical improvements in memory performance [2].
    [Show full text]
  • Implementation Notes
    IMPLEMENTATION NOTES XEROX 3102464 lyric Release June 1987 XEROX COMMON LISP IMPLEMENTATION NOTES 3102464 Lyric Release June 1987 The information in this document is subject to change without notice and should not be construed as a commitment by Xerox Corporation. While every effort has been made to ensure the accuracy of this document, Xerox Corporation assumes no responsibility for any errors that may appear. Copyright @ 1987 by Xerox Corporation. Xerox Common Lisp is a trademark. All rights reserved. "Copyright protection claimed includes all forms and matters of copyrightable material and information now allowed by statutory or judicial law or hereinafter granted, including, without limitation, material generated from the software programs which are displayed on the screen, such as icons, screen display looks, etc. " This manual is set in Modern typeface with text written and formatted on Xerox Artificial Intelligence workstations. Xerox laser printers were used to produce text masters. PREFACE The Xerox Common Lisp Implementation Notes cover several aspects of the Lyric release. In these notes you will find: • An explanation of how Xerox Common Lisp extends the Common Lisp standard. For example, in Xerox Common Lisp the Common Lisp array-constructing function make-array has additional keyword arguments that enhance its functionality. • An explanation of how several ambiguities in Steele's Common Lisp: the Language were resolved. • A description of additional features that provide far more than extensions to Common Lisp. How the Implementation Notes are Organized . These notes are intended to accompany the Guy L. Steele book, Common Lisp: the Language which represents the current standard for Co~mon Lisp.
    [Show full text]