DOCSLIB.ORG

Object Oriented Programming (OOP) Imperative Programming

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Object Oriented Programming (OOP) Imperative Programming Object Oriented Programming (OOP) IIIA o New programming paradigm o Actions Æ Objects o Objects Å Actions o Object-oriented = Objects + Classes + Inheritance TAPIA 2005-2006 Imperative programming IIIA o OOP (Object-Oriented Programming) related o Local state, delegation, inheritance o History (Norvig,465): Algol 60 Æ SIMULA o Lisp extensions: o Smalltalk (69) o Flavors (79) o New Flavors (81) o Common Loops (88) o CLOS (91): standard TAPIA 2005-2006 History IIIA Dahl 1966 Algol60 Simula Classes single inheritance Nygaard LISP world Kay 1969 Smalltalk Goldberg Ingalls Steele 1976 LAMBDA Cannon 1979 Flavors multiple inheritance method combination Weinreb Symbolics 1981 New Flavors generic functions Xerox 1982 CommonLoops multimethods AT&T 1986 C++ Bell labs Meyer 1988 Oaklisp Eiffel Lang 1988 Perlmutter CLOS Steele 1991 JAVA TAPIA 2005-2006 AOP vs. OOP (Shoham) IIIA OOP AOP Basic unit Object (passive) Agent (active) State without restriction belief, commitment, competence, preferences, … Computation Message passing, methods Message passing, methods Type of messages without restriction Inform, request, offer, promise, reject, … Message no Honesty, consistency, rationality, restrictions … TAPIA 2005-2006 Nomenclature IIIA o Object: encapsulated local state and behavior o Class: describes similar objects with the same behavior and structure. o Instance: object belonging to a class. o Class Variable: variable shared by all the members of a class. o Instance Variable: encapsulated variable of an object. o Generic Function: its behavior depends on the types or classes of the arguments. TAPIA 2005-2006 Nomenclature IIIA o Message: Action name. Equivalent to a generic function. o Method: Specialization of a generic function. o Delegation: an object passes a task to another object. o Multimethod: method with more than one argument o Inheritance: to define new classes that are a specialization of a more general one. o Multiple inheritance: from more than one father class. TAPIA 2005-2006 Object-Oriented Style IIIA o Example: Bank account class o Local state and functions o Instance variables: balance, interest rate o Messages and methods: withdraw, deposit, balance, name, interest o It is not possible to manipulate the variables in a closure using CommonLisp. o INSPECT is implementation dependent TAPIA 2005-2006 Object-Oriented Style IIIA (defun new-account (name &optional (balance 0.00) (interest-rate .06)) “new account with the following messages:" #'(lambda (message) (case message (withdraw #'(lambda (amt) (if (<= amt balance) (decf balance amt) 'insufficient-funds))) (deposit #'(lambda (amt) (incf balance amt))) (balance #'(lambda () balance)) (name #'(lambda () name)) (interest #'(lambda () (incf balance (* interest-rate balance))))))) TAPIA 2005-2006 SEND IIIA o Send function (Flavors) implements the control of objects. (defun get-method (object message) “Returns the method for the given message" (funcall object message)) (defun send (object message &rest args) “Applies the method for the message with the arguments” (apply (get-method object message) args)) TAPIA 2005-2006 SEND IIIA o Execution examples > (setf acct (new-account "J. Random Customer" 1000.00)) #<CLOSURE 23652465> > (send acct 'withdraw 500.00) Æ 500.0 > (send acct 'deposit 123.45) Æ 623.45 > (send acct 'name) Æ "J. Random Customer" > (send acct 'balance) Æ 623.45 TAPIA 2005-2006 Generic functions IIIA o The syntax of send is not useful. We are interested in expressions of the following type: o (mapcar 'balance accounts) o Using messages: o (mapcar #'(lambda (acct) (send acct 'balance)) accounts) o Generic functions will find the correct method of an object, specialized on a message type. o (defun withdraw (object &rest args) “withdraw is a generic function over objects." (apply (get-method object 'withdraw) args)) o We can write: o (withdraw acct x) o Instead of: o (send acct 'withdraw x) TAPIA 2005-2006 Classes IIIA o Using Macros o Easier read and write object-oriented code o Create a new class o Methods o Generic functions for each message o Class variables o Instance variables TAPIA 2005-2006 Classes IIIA (define-class account (name &optional (balance 0)) ((interest-rate .06)) (withdraw (amt) (if (<= amt balance (decf balance amt) 'insufficient-funds)) (deposit (amt) (incf balance amt)) (balance () balance) (name () name) (interest () (incf balance (* interest-rate balance)))) TAPIA 2005-2006 Classes IIIA (defmacro define-class (class inst-vars class-vars &body methods) “class definition." `(let ,class-vars (mapcar #'ensure-generic-fn ' ,(mapcar #'first methods)) (defun ,class ,inst-vars #'(lambda (message) (case message ,@(mapcar #'make-clause methods)))))) (defun make-clause (clause) "Translate a message from define-class into a case clause." `(,(first clause) #'(lambda ,(second clause) ,@(rest (rest clause))))) TAPIA 2005-2006 Classes II IIIA (defun ensure-generic-fn (message) “defines a generic function." (unless (or (generic-fn-p message) (eq message ‘otherwise)) (let ((fn #'(lambda (object &rest args) (apply (get-method object message) args)))) (setf (symbol-function message) fn) (setf (get message 'generic-fn) fn)))) (defun generic-fn-p (fn-name) “is fn-name a function?" (and (fboundp fn-name) (eq (get fn-name 'generic-fn) (symbol-function fn-name)))) TAPIA 2005-2006 Classes II IIIA (define-class account (name &optional (balance 0)) ((interest-rate .06)) (withdraw (amt) (if (<= amt balance (decf balance amt) 'insufficient-funds)) (deposit (amt) (incf balance amt)) (balance () balance) (name () name) (interest () (incf balance (* interest-rate balance)))) TAPIA 2005-2006 Classes III IIIA o Macro expansion: (LET ((INTEREST-RATE 0.06)) (MAPCAR #'ENSURE-GENERIC-FN '(WITHDRAW DEPOSIT BALANCE NAME INTEREST)) (DEFUN ACCOUNT (NAME &OPTIONAL (BALANCE 0.0)) #'(LAMBDA (MESSAGE) (CASE MESSAGE (WITHDRAW #'(LAMBDA (AMT) (IF (<= AMT BALANCE) (DECF BALANCE AMT) 'INSUFFICIENT-FUNDS))) (DEPOSIT #'(LAMBDA (AMT) (INCF BALANCE AMT))) (BALANCE #'(LAMBDA NIL BALANCE)) (NAME #'(LAMBDA NIL NAME)) (INTEREST #'(LAMBDA NIL (INCF BALANCE (* INTEREST-RATE BALANCE)))))))) TAPIA 2005-2006 Classes III IIIA o Using the new objects: o > (setf acct2 (account "A. User" 2000.00)) #<CLOSURE 24003064> o > (deposit acct2 42.00) -> 2042.0 o > (interest acct2) -> 2164.52 o > (balance acct2) -> 2164.52 Previous !!! o > (balance acct) -> 623.45 object TAPIA 2005-2006 Delegation I IIIA o Account with password: (define-class password-account (password acct) () (change-password (pass new-pass) (if (equal pass password) (setf password new-pass) 'wrong-password)) (otherwise (pass &rest args) (if (equal pass password) (apply message acct args) 'wrong-password))) TAPIA 2005-2006 Delegation I IIIA o Details of the define-class macro: message and otherwise. > (setf acct3 (password-account "secret" acct2)) #<CLOSURE 33427277> > (balance acct3 "secret") -> 2164.52 > (withdraw acct3 "guess" 2000.00) -> WRONG-PASSWORD > (withdraw acct3 "secret" 2000.00) -> 164.52 TAPIA 2005-2006 Delegation II IIIA o The same technique for “limited” accounts: (define-class limited-account (limit acct) () (withdraw (amt) (if (> amt limit) 'over-limit (withdraw acct amt))) (otherwise (&rest args) (apply message acct args))) TAPIA 2005-2006 Delegation II IIIA o > (setf acct4 (password-account "pass" (limited-account 100.00 (account "A. Thrifty Spender" 500.00)))) #<CLOSURE 34136775> o > (withdraw acct4 "pass" 200.00) Æ OVER-LIMIT o > (withdraw acct4 "pass" 20.00) Æ 480.0 o > (withdraw acct4 "guess" 20.00) WRONG-PASSWORD TAPIA 2005-2006 Delegation III IIIA o Each class implements a different withdraw method. Sending the message withdraw to the object acct4 : 1. password-account method validates the password. 2. If correct, sends the message withdraw to the limited-account object. 3. If under the limit, sends the message withdraw to the account object. o Notice the differences with the procedural version (defun withdraw (acct amt &optional pass) (cond ((and (typep acct 'password-account) (not (equal pass (account-password acct)))) 'wrong-password) ((and (typep acct 'limited-account) (> amt (account-limit account))) 'over-limit) ((> amt balance) 'insufficient-funds) (t (decf balance amt)))) TAPIA 2005-2006 Inheritance I IIIA o Classes are hierarchically organized. It is necessary to make explicit this hierarchy. o Lisp structures implement inheritance: (defstruct (limited-account (:include account)) limit) o The same for classes: (define-class limited-account account (limit) () (withdraw (amt) (if (>amt limit) 'over-limit (call-next-method))) TAPIA 2005-2006 Inheritance II IIIA o Multiple inheritance : (define-class limited-account-with-password (password-account limited-account)) o Union of the functionalities belonging to the two classes. o No new variable or methods. TAPIA 2005-2006 History IIIA Dahl 1966 Algol60 Simula Classes single inheritance Nygaard LISP world Kay 1969 Smalltalk Goldberg Ingalls Steele 1976 LAMBDA Cannon 1979 Flavors multiple inheritance method combination Weinreb Symbolics 1981 New Flavors generic functionsCommon Lisp Object System Xerox 1982 CommonLoops multimethods AT&T 1986 C++ Bell labs Meyer 1988 Oaklisp Eiffel Lang 1988 Perlmutter CLOS Steele 1991 JAVA TAPIA 2005-2006 CLOS: defclass IIIA Our System CLOS define-class defclass methods in class defmethod class-name make-instance call-next-method call-next-method ensure-generic-fn ensure-generic-function o Definition of: o Classes: defclass o Methods: delmethod o Instances: make-instance. o Syntax of class definition: (defclass class-name (superclass...)
Load more

Recommended publications
  • Genera Workbook Using This Book Preface This Is the Document To
    Genera Workbook Using This Book Preface This is the document to read when you’re ready to sit down at your Symbol- ics computer. It teaches you the initial skills you need to use the Genera system effectively. We present concepts you need to know, as well as providing exercises andactivitiesthatturnthoseconceptsintopracticalskills. The material covered in the first group of chapters in this workbook is a pre- requisite for all Symbolics Education Services Courses. However, you can com plete the second and third sections after taking your first course. Practicing the material helpsyou learn it faster. Bring this workbook to all courses you take with Symbolics. We expect that you have used a computer before; we do not expect that you have used a Symbolics computer before. You need to learn this material whether or not you are a programmer. This is not a programming textbook. We make no assumptions about your programming background or future; this work bookisforbothprogrammersandnonprogrammers. Every time we use a term for the first time, we put it in italics. If you see a term you don’t recognize, be sure to check the glossary at the end of the work book. This workbook uses Symbolics documentation conventions and a few of its own. If you see a word or phrase enclosed in brackets, like [Help], it is a menu item.We use two different conventions withrespect to Symbolics keyboard keys: in text,thekeylabelledHELPlookslikethis: HELP butinexamplesitlookslikethis: <HELP> todifferentiateitasasinglekeystrokefromthetextaroundit. It is very important to have a Symbolics computer available so that you can work through the hands-on activities, called walk-throughs.
    [Show full text]
  • Equal Rights for Functional Objects Or, the More Things Change, The
    ACM OOPS Messenger 4,4 (Oct. 1993), 2-27. Equal Rights for Functional Objects1 or, The More Things Change, The More They Are the Same2 Henry G. Baker Nimble Computer Corporation 16231 Meadow Ridge Way, Encino, CA 91436 (818) 986-1436 (818) 986-1360 FAX August, October, 1990, October, 1991, and April, 1992 This work was supported in part by the U.S. Department of Energy Contract No. DE-AC03-88ER80663 We argue that intensional object identity in object-oriented programming languages and databases is best defined operationally by side-effect semantics. A corollary is that "functional" objects have extensional semantics. This model of object identity, which is analogous to the normal forms of relational algebra, provides cleaner semantics for the value-transmission operations and built-in primitive equality predicate of a programming language, and eliminates the confusion surrounding "call-by-value" and "call-by-reference" as well as the confusion of multiple equality predicates. Implementation issues are discussed, and this model is shown to have significant performance advantages in persistent, parallel, distributed and multilingual processing environments. This model also provides insight into the "type equivalence" problem of Algol-68, Pascal and Ada. 1. INTRODUCTION Parallel, distributed and persistent programming languages are leaving the laboratories for more wide-spread use. Due to the substantial differences between the semantics and implementations of these languages and traditional serial programming languages, however, some of the most basic notions of programming languages must be refined to allow efficient, portable implementations. In this paper, we are concerned with defining object identity in parallel, distributed and persistent systems in such a way that the intuitive semantics of serial implementations are transparently preserved.
    [Show full text]
  • The Evolution of Lisp
    1 The Evolution of Lisp Guy L. Steele Jr. Richard P. Gabriel Thinking Machines Corporation Lucid, Inc. 245 First Street 707 Laurel Street Cambridge, Massachusetts 02142 Menlo Park, California 94025 Phone: (617) 234-2860 Phone: (415) 329-8400 FAX: (617) 243-4444 FAX: (415) 329-8480 E-mail: [email protected] E-mail: [email protected] Abstract Lisp is the world’s greatest programming language—or so its proponents think. The structure of Lisp makes it easy to extend the language or even to implement entirely new dialects without starting from scratch. Overall, the evolution of Lisp has been guided more by institutional rivalry, one-upsmanship, and the glee born of technical cleverness that is characteristic of the “hacker culture” than by sober assessments of technical requirements. Nevertheless this process has eventually produced both an industrial- strength programming language, messy but powerful, and a technically pure dialect, small but powerful, that is suitable for use by programming-language theoreticians. We pick up where McCarthy’s paper in the first HOPL conference left off. We trace the development chronologically from the era of the PDP-6, through the heyday of Interlisp and MacLisp, past the ascension and decline of special purpose Lisp machines, to the present era of standardization activities. We then examine the technical evolution of a few representative language features, including both some notable successes and some notable failures, that illuminate design issues that distinguish Lisp from other programming languages. We also discuss the use of Lisp as a laboratory for designing other programming languages. We conclude with some reflections on the forces that have driven the evolution of Lisp.
    [Show full text]
  • Comparative Studies of 10 Programming Languages Within 10 Diverse Criteria
    Department of Computer Science and Software Engineering Comparative Studies of 10 Programming Languages within 10 Diverse Criteria Jiang Li Sleiman Rabah Concordia University Concordia University Montreal, Quebec, Concordia Montreal, Quebec, Concordia [email protected] [email protected] Mingzhi Liu Yuanwei Lai Concordia University Concordia University Montreal, Quebec, Concordia Montreal, Quebec, Concordia [email protected] [email protected] COMP 6411 - A Comparative studies of programming languages 1/139 Sleiman Rabah, Jiang Li, Mingzhi Liu, Yuanwei Lai This page was intentionally left blank COMP 6411 - A Comparative studies of programming languages 2/139 Sleiman Rabah, Jiang Li, Mingzhi Liu, Yuanwei Lai Abstract There are many programming languages in the world today.Each language has their advantage and disavantage. In this paper, we will discuss ten programming languages: C++, C#, Java, Groovy, JavaScript, PHP, Schalar, Scheme, Haskell and AspectJ. We summarize and compare these ten languages on ten different criterion. For example, Default more secure programming practices, Web applications development, OO-based abstraction and etc. At the end, we will give our conclusion that which languages are suitable and which are not for using in some cases. We will also provide evidence and our analysis on why some language are better than other or have advantages over the other on some criterion. 1 Introduction Since there are hundreds of programming languages existing nowadays, it is impossible and inefficient
    [Show full text]
  • Symbolics Architecture
    Symbolics Architecture David A. Moon Symbolics, Inc. W hat is an architecture? In com- languages, user interface, and operating This architecture puter systems, an architecture system. System architecture defines the rapid is a specification of an inter- product that people actually use; the other enables face. To be dignified by the name architec- levels of architecture define the mecha- development and ture, an interface should be designed for a nism underneath that implements it. Sys- long lifespan and should connect system tem architecture is implemented by soft- efficient execution of components maintained by different orga- ware; hardware only sets bounds on what large, ambitious nizations. Often an architecture is part ofa is possible. System architecture defines the product definition and defines character- motivation for most of the design choices applications. An istics on which purchasers of that product at the other levels ofarchitecture. This sec- rely, but this is not true of everything that tion is an overview of Symbolics system unconventional design is called an architecture. An architecture is architecture. avoids trading off more formal than an internal interface be- The Symbolics system presents itself to tween closely-related system components, the user through a high-resolution bitmap safety for speed. and has farther-reaching effects on system display. In addition to text and graphics, characteristics and performance. the display contains presentations of ob- A computer system typically contains jects. The user operates on the objects by many levels and types ofarchitecture. This manipulating the presentations with a article discusses three architectures de- mouse. The display includes a continuous- fined in Symbolics computers: ly updated reminder of the mouse com- (1) System architecture-defines how mands applicable to the current context.
    [Show full text]
  • Free As in Freedom (2.0): Richard Stallman and the Free Software Revolution
    Free as in Freedom (2.0): Richard Stallman and the Free Software Revolution Sam Williams Second edition revisions by Richard M. Stallman i This is Free as in Freedom 2.0: Richard Stallman and the Free Soft- ware Revolution, a revision of Free as in Freedom: Richard Stallman's Crusade for Free Software. Copyright c 2002, 2010 Sam Williams Copyright c 2010 Richard M. Stallman Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled \GNU Free Documentation License." Published by the Free Software Foundation 51 Franklin St., Fifth Floor Boston, MA 02110-1335 USA ISBN: 9780983159216 The cover photograph of Richard Stallman is by Peter Hinely. The PDP-10 photograph in Chapter 7 is by Rodney Brooks. The photo- graph of St. IGNUcius in Chapter 8 is by Stian Eikeland. Contents Foreword by Richard M. Stallmanv Preface by Sam Williams vii 1 For Want of a Printer1 2 2001: A Hacker's Odyssey 13 3 A Portrait of the Hacker as a Young Man 25 4 Impeach God 37 5 Puddle of Freedom 59 6 The Emacs Commune 77 7 A Stark Moral Choice 89 8 St. Ignucius 109 9 The GNU General Public License 123 10 GNU/Linux 145 iii iv CONTENTS 11 Open Source 159 12 A Brief Journey through Hacker Hell 175 13 Continuing the Fight 181 Epilogue from Sam Williams: Crushing Loneliness 193 Appendix A { Hack, Hackers, and Hacking 209 Appendix B { GNU Free Documentation License 217 Foreword by Richard M.
    [Show full text]
  • A Lisp Oriented Architecture by John W.F
    A Lisp Oriented Architecture by John W.F. McClain Submitted to the Department of Electrical Engineering and Computer Science in partial fulfillment of the requirements for the degrees of Master of Science in Electrical Engineering and Computer Science and Bachelor of Science in Electrical Engineering at the MASSACHUSETTS INSTITUTE OF TECHNOLOGY September 1994 © John W.F. McClain, 1994 The author hereby grants to MIT permission to reproduce and to distribute copies of this thesis document in whole or in part. Signature of Author ...... ;......................... .............. Department of Electrical Engineering and Computer Science August 5th, 1994 Certified by....... ......... ... ...... Th nas F. Knight Jr. Principal Research Scientist 1,,IA £ . Thesis Supervisor Accepted by ....................... 3Frederic R. Morgenthaler Chairman, Depattee, on Graduate Students J 'FROM e ;; "N MfLIT oARIES ..- A Lisp Oriented Architecture by John W.F. McClain Submitted to the Department of Electrical Engineering and Computer Science on August 5th, 1994, in partial fulfillment of the requirements for the degrees of Master of Science in Electrical Engineering and Computer Science and Bachelor of Science in Electrical Engineering Abstract In this thesis I describe LOOP, a new architecture for the efficient execution of pro- grams written in Lisp like languages. LOOP allows Lisp programs to run at high speed without sacrificing safety or ease of programming. LOOP is a 64 bit, long in- struction word architecture with support for generic arithmetic, 64 bit tagged IEEE floats, low cost fine grained read and write barriers, and fast traps. I make estimates for how much these Lisp specific features cost and how much they may speed up the execution of programs written in Lisp.
    [Show full text]
  • CLX — Common LISP X Interface
    CLX Common LISP X Interface 1988, 1989 Texas Instruments Incorporated Permission is granted to any individual or institution to use, copy, modify and distribute this document, provided that this complete copyright and permission notice is maintained, intact, in all copies and supporting documentation. Texas Instruments Incorporated makes no representations about the suitability of this document or the software described herein for any purpose. It is provided ”as is” without express or implied warranty. CLX Programmer’s Reference i ACKNOWLEDGMENTS Primary Interface Author: Robert W. Scheifler MIT Laboratory for Computer Science 545 Technology Square, Room 418 Cambridge, MA 02139 [email protected] Primary Implementation Author: LaMott Oren Texas Instruments PO Box 655474, MS 238 Dallas, TX 75265 [email protected] Design Contributors: Dan Cerys, BBN Scott Fahlman, CMU Kerry Kimbrough, Texas Instruments Chris Lindblad, MIT Rob MacLachlan, CMU Mike McMahon, Symbolics David Moon, Symbolics LaMott Oren, Texas Instruments Daniel Weinreb, Symbolics John Wroclawski, MIT Richard Zippel, Symbolics Documentation Contributors: Keith Cessna, Texas Instruments Kerry Kimbrough, Texas Instruments Mike Myjak LaMott Oren, Texas Instruments Dan Stenger, Texas Instruments The X Window System is a trademark of MIT. UNIX is a trademark of AT&T Bell Laboratories. ULTRIX, ULTRIX–32, ULTRIX–32m, ULTRIX–32w, and VAX/VMS are trademarks of Digital Equipment Corporation. ii CLX Programmer’s Reference CONTENTS Section Title 1 INTRODUCTION TO CLX 2 DISPLAYS 3 SCREENS 4 WINDOWS AND PIXMAPS 5 GRAPHICS CONTEXTS 6 GRAPHIC OPERATIONS 7 IMAGES 8 FONTS AND CHARACTERS 9 COLORS 10 CURSORS 11 ATOMS, PROPERTIES, AND SELECTIONS 12 EVENTS AND INPUT 13 RESOURCES 14 CONTROL FUNCTIONS 15 EXTENSIONS 16 ERRORS A PROTOCOL VS.
    [Show full text]
  • Genera User's Guide Overview of Symbolics Computers
    Genera User’s Guide Overview of Symbolics Computers Documentation Notation Conventions Modifier Key Conventions Modifier keys are designed to be held down while pressing other keys. They do not themselves transmit characters. A combined keystroke like META-X is pronounced "meta x" and written as m-X.This notation means thatyou press the META key and, whileholdingitdown,presstheXkey. Modifierkeysareabbreviatedasfollows: CONTROL c- META m- SUPER s- HYPER h- SHIFT sh- SYMBOL sy- Modifier keys can be used in combination, as well as singly.Forexample, the nota tion c-m-Y indicates that you should hold down both the CONTROL and the META keyswhilepressingY. Modifier keys can also be used, both singly and in combination, to modify mouse commands. For example, the notation sh-Left means hold down the SHIFT key while clicking Left on the mouse and c-m-Middle means hold down CONTROL and METAwhileclickingMiddle. The keys with white lettering (like X or SELECT) all transmit characters. Combina tions of these keys should be pressed in sequence, one after the other (for exam ple, SELECT L). This notation means that you press the SELECT key, release it, and thenpresstheLkey. LOCAL is an exception to this rule. Despite its white lettering, you must hold it down while pressing another key, or it has no effect. For example, to brighten the imageonyourmonitor,youwouldholddown LOCALwhilepressingB. Page 2736 Documentation Conventions Thisdocumentationusesthefollowingnotationconventions: cond,zl:hostat PrintedrepresentationofLispobjectsinrunningtext. RETURN,ABORT,c-F keysontheSymbolicsKeyboard. SPACE Spacebar. login Literaltypein. (make-symbol "foo") Lispcodeexamples. (function-name arg1 &optionalarg2) Syntaxdescriptionoftheinvocationoffunction-name. arg1 Argument to the function function-name, usually ex pressed as a word that reflects the type of argument (forexample,string).
    [Show full text]
  • Genera Concepts Genera the Best Software Environment Available
    Genera Concepts Genera The Best Software Environment Available To allournewusers:Welcome. This conceptual introduction explains what your Symbolics computer is all about. We urge you to at least skim it before you start daily work with the system. We try here to summarize some of the "big picture" concepts in your new software environment; knowing about this framework will help you in learning its details moreefficiently. Most new users of Symbolics machines have worked on traditional timesharing systems, such as VAX/VMS, or on microcomputers or conventional UNIX worksta tions. ("Genera Comparison Charts" shows some equivalents between these systems and Genera.) If you feel somewhat uneasy about learning how to use the most ad vancedsoftwareenvironmentaround,relax! You don’t have to learn everything at once in order to do anything look at this as a longterm, incrementallearning project. You don’t have to learn everything by yourself.OurdocumentationandGeneraitselfareheretohelpyou. Genera and Symbolics Common Lisp dramatically increase your productivity and efficiency by providing many builtin software facilities (similar to library routines) that you would otherwise have to write yourself. Our editcompiledebug cycle hap pens so fast that you are virtually editing, compiling, and debugging simultaneous ly. The editor, compiler and debugger are all resident utilities, available anytime, anywhere. Lisp Your Editor Mail Listener Application Figure173.YourviewofGenera’scommandlevel. Page 2926 "command levels" or separate "commandenvironments;" you can get Genera has no there from here. You can move directly from any application to any other applica tion, usually with just two keystrokes. You do not have to close one application to enteranother.(SeeFigure173.) Many different activities, such as the editor and electronic mail, run at the same time in separate processes.
    [Show full text]
  • Common Lisp Object System
    Common Lisp Object System by Linda G. DeMichiel and Richard P. Gabriel Lucid, Inc. 707 Laurel Street Menlo Park, California 94025 (415)329-8400 [email protected] [email protected] with Major Contributions by Daniel Bobrow, Gregor Kiczales, and David Moon Abstract The Common Lisp Object System is an object-oriented system that is based on the concepts of generic functions, multiple inheritance, and method combination. All objects in the Object System are instances of classes that form an extension to the Common Lisp type system. The Common Lisp Object System is based on a meta-object protocol that renders it possible to alter the fundamental structure of the Object System itself. The Common Lisp Object System has been proposed as a standard for ANSI Common Lisp and has been tentatively endorsed by X3J13. Common Lisp Object System by Linda G. DeMichiel and Richard P. Gabriel with Major Contributions by Daniel Bobrow, Gregor Kiczales, and David Moon 1. History of the Common Lisp Object System The Common Lisp Object System is an object-oriented programming paradigm de- signed for Common Lisp. Over a period of eight months a group of five people, one from Symbolics and two each from Lucid and Xerox, took the best ideas from CommonLoops and Flavors, and combined them into a new object-oriented paradigm for Common Lisp. This combination is not simply a union: It is a new paradigm that is similar in its outward appearances to CommonLoops and Flavors, and it has been given a firmer underlying semantic basis. The Common Lisp Object System has been proposed as a standard for ANSI Common Lisp and has been tentatively endorsed by X3J13.
    [Show full text]
  • Oaklisp: an Object-Oriented Scheme with First Class Types
    Oaklisp: an Object-Oriented Scheme with First Class Types Kevin J. l,ang and llarak A. Peaflmutter Department of Computer Science Carnegie-Mellon University Pittsburgh, PA 15213 Abstract several implications that are not immediately obvious. Because • The Scheme papers demonstrated that lisp could be made simpler function can be applied at a point distant in time and space from ilz and more expressive by elevating functions to the level of first class point of origin, it must be able to remember the bindings of any objects. Oaklisp shows that a message based language can derive variables that were visible when it was made. This additional similar benefits from having first class types. complexity is offset by the ability to write many previously primitive control structures at the user level and by the fact that the special Introduction mechanisms that lisp ordinarily uses for defining and applying Oaklisp is a message based, multiple inheritence dialect of lisp. functions can be dispensed with. Programs are written using lisp syntax, and traditional lisp data types In lisp, the car position of a function call is treated as the name of a coexist with a Smalltalk style class hierarchy. This paper assumes that function which is looked up in a special table and then applied to the the reader is familiar with one of the many object-oriented lisp dialects values obtained by evaluating the arguments of the call. In Scheme, the of this sort. and will therefore concentrate on the unique aspects of car of a call is an evaluated position. Although any expression can Oaklisp which are mostly due to the influence of Scheme.
    [Show full text]